Integration Shift - Restful Constraints

REST stands for Representational State Transfer. It is resource based (in spite of action based) architectural style  which supports http protocol.

Resources are identified by URIs and it is the representation of resources  that is transferred between client & server. When client get the representation of a resource, it should have enough information to identify, modify, delete the resource on server, given it has appropriate permissions . Just for an example, user can be a resource which can be a database entity with 20 attributes and its representation can be userID, name, email address and one or combination of these attribute should be enough to uniquely identify a user.

REST has following design constraints:

Client-Server - This means that api solution should be implemented as client side (for eg: browser) which retrieves the data, and server side which hosts the business logic & data. It enables separation of concerns which keeps user interface design separate from service design. Implementation of this constraint assumes a disconnected system for eg: client side implementation may not have have direct connection to databases/ resources.

Stateless: This constraint specifies that each request is independent irrespective of the order and have enough context to process the message. Any session state is maintained at the client side.  For eg:

- Each request should have a token which mentions that user is authenticated.

- Each request has their pagination tag to specify the dataset expected in the response.

- 3 Legged OAuth is a stateful api, though built in a restful approach.

Uniform Interface - This means request from client to server is handled through a uniform interface. This can be explained as follows:

- URIs as a standard way of identify resources (/users, /products)

- Manipulation of resources through standard interface (GET, POST, PUT, DELETE) (users/1)

- Messages are self descriptive with standard http responses, caching and processing instructions.

- HATEOAS - Hypermedia as an engine of application state. Response from the API call has links which specifies how to use the API. An example may be API response contain key like “current_user_url” specifying link like “https://api.example.com/user”

Cacheable - This means that response message from the server specifies whether it’s cacheable. Caching response helps improve network & application performance.

- GET, PUT, DELETE request are idempotent and responses from these request are cacheable whereas POST changes the state on the server is not really cacheable.

- Usually server responses contain expiry time which specifies the cacheing duration.

- Etags specified in the request are checked whether the content has been changed and serve as caching signals.

- With caching, HEAD request can be enough to generate the response as client can use the cache data for response.

Layered System -  With this constraint, client cannot assume that it is directly interacting with the server. This allows API management companies to add load balancing, cacheing, logging, analytics without affecting the design of the API.

Code on Demand - It is only optional constraint through which server can extent client by transferring executable logic to client, for eg: in the form of javascript & applets.

In my next post, I will write about how these constraints help in achieving goals of REST architecture.