REST – Representational State Transfer
—- It is an Architectural Style and not a Standard
- Everything is considered as Resource.
- Every Resource is identified by URI
- Stateless – Every Request/Response should contain enough information for exchanging data.
- Message format – XML, JSON, Custom format
- It is based on HTTP
- SImple HTTP is used for communication between machines.
- Uses HTTP methods ( GET, POST, PUT, DELETE, HEAD) for all CRUD operations
- Platform Independent ( Server – Unix, Client -Windows)
- Language independent ( Server – C# , Client – Java)
- Can be used in presence of firewall
- HTTP Accept headers no accepted should return 406 response
- OPTIONS – Use this to know which HTTP methods are supported by a resource
- PATCH – used for updating only partial resource
- 4XX error code – convey some error happened on the client side. It should not send the same request again
- 5XX error code – Issue is on the server side. Example DB is down or etc. Example client is sending a request to add a record in the DB. In this case Client can send the same request
Does Not Offer
- built – in Security features – Can use username/tokens for security along with the webservice
- Encryption – Can be on top of HTTPS
- Session Management
Why Rest ?
- Scalability – Large no of interconnected machine able to communicate seamlessly
- Generality – Based on HTTP standard.
- Independent – Client server are independent and are loosely coupled.
- Security – Follow HTTP specification
- HATEOAS – Hypermedia As The Engine Of Application State
6 Constraints in REST
- All resources are identified using URI/URLS
- Resources are different from representation(JSON,XML etc)
- Clients can manipulate the resources
- Client and Server cannot persist any context about the other. The request/response should contain all required information as part of header, URL etc
- Client can cache the response.
- Response can decide if it can be persisted on the client side
- They are loosely coupled.
- At any point of time client cannot say if it is connected to end server or intermediate server as real URLS should not be used.
- Nouns and not verbs.
- Coarse Grained and not Fine Grained
- Coarse Grained – UserService.setUserDetails(userObj)
- Fine Frained – UserService.setUID(String uid), UserService.setUserName(String userName)
- 2 types
- Collection – ../applications —> returns all the applications
- Instance – ../applications/abcxyz – returns only the specific app ( abcxyz)
- IDEMPOTENT – Always return the same server state for every request.
- GET – Used for READ
- PUT – Used for create/update. Should always send complete data of the resource for create/update as it is idempotent
- HEAD – headers, no body
- POST – Used for create/update. Can send partial data while creation. Later can use partial data for update as it is not idempotent
It is the content type of the request and response. Format Specification + Parsing type
Request: Specifies “Accept” with type in the header
Response: content-type: application/json, application/foo+json;application etc
How are rest APi’s accessed
Should design to return the same data format across various REST clients
- Browser – Calling a REST API if it returns JSON resource.
- Rest Client – Return same JSON resource here as well
Versioning can be done through 2 ways
- URL Versioning
- Set the version in the content-type as application/foo+json;application&v=1
- Can use any no.of version as the URI will remain unchanged
- Client can choose when they want to upgrade to new version
- Best practice, but not used widely
Use myArray.forEach and not myArray.for_each
Date/Time – Use ISO 8610 – UTC
- Resources can access other resources using HREF in REST
- XML uses XLINK
- Example : Employee resource would like to display the Department details. In this case Employee JSON can have a HREF to Department Resource URI
When header is not supported – resource extensions can be used as follows
/application/abcyz.json , /application/abcyz.csv . This overrides the Accept header.
Authentication in REST
- HTTP Auth
- UserName/Password is prompted when the user request for the rest api. The browser caches the credentials and sends it along every request
- Password should be sent with every request
- No prevention from tampering the header or body
- HMAC – Hash based message authentication
- Password is hashed along with more information like timestamp etc
- Prevents eavesdropping and replay attacks.
- Login Service like OAuth
- Accept credential and generate the tokens.
- Token will be included as part of URL param as &authToken=XYZ
- Tokens can be created with expiration date.
- Should not be used as it violates the “Stateless” feature of REST