What is OData? (Part-2)

In my previous blog, I discussed how the Internet works and gave an introduction to what is HTTP and the difference between URL and URI. IN this blog we will discuss REST-based APIs.

Previous Blogs in the series:

What is OData? (Part-1)

What is REST?

REST or REpresentational State Transfer is an architectural style that uses a simple and lightweight mechanism for inter-machine communication. It is an alternative to the RPC (Remote Procedure Calls) and Web Services.

REST is resource-based unlike RPC or SOAP which are action-based. In SOAP you will have a request to get material data whereas, in REST, the material will be identified as a resource using URI and then use HTTP verbs to determine which operation shall be performed on the resource. It is important to note here that it is possible to have multiple URIs pointing to the same resource.

Representation of the resource is not the resource itself but only a representation.

The term representation is how the resources are manipulated in a rest based architecture

Representations depicts parts of the resource state which are transferred between client and server is mostly JSON or XML format. The client will typically have enough information to manipulate the resource on the server.  For example, if a Person is modeled as a resource and there is a service to get contact information of a person then the representation that you will get of that Person would be Name, Address, and Phone details in JSON or XML format.

The Six Constraints

The following are the six constraints defined which are attributes of a RESTful API.

1. Uniform Interface

Uniform Interface is fundamental to the design of any REST-based service. The uniform interface simplifies and decouples the architecture, which enables each part to evolve independently.

What that means is that it should be possible to identify the individual resource in the request, for example using URI. Once the Client has a representation of the Resource then, it should have enough information to update or delete the resource. And that the Client should not assume that any particular action is available on a resource beyond those described in the representation received from the server previously.

2. Stateless

The Server should not contain any Client state. It is possible to process a request only if they are self-descriptive and that the request should have enough context to act upon. For example, if the Person resource address needs to be updated then it is required that the Client passes on the particular Person resource details in the request for which it has received the representation from the Server in the previous request. If the state has to be maintained, it should be at the Client side.

3. Client-Server

We have already established this constraint that the RESTful architecture is a Client-Server architecture. Resource representations are transferred between client and server. We should always keep at the back of our minds that the Client of RESTful APIs will not have direct connections to the Resources.

4. Cacheable

Another constraint on a RESTful API is that any response that is coming from the Server should be cacheable on the Client side. Caching could be implicit, explicit, or negotiable. Implicit and Explicit caching is self-explanatory whereas Negotiable caching means that the Server and Client agree on how long a representation can be cached on the Client.

5. Layered System

The constraint of the Layered System is closely related to the above two constraints of Client-Server and Cacheable. It suggests that the Client of a RESTful API should not assume that there will be a direct connection between the client and the server. There could be multiple layers of software or/and hardware in between the two. The Client needs not to know whom exactly it is talking to and whether a response is coming from the server or is accessed from a local cache. This improves scalability.

6. Code on Demand

This constrains suggests that it should be possible that a Server can extend a Client temporarily. It means that the Server can transfer logic to the client as a representation to be executed at the client.

This is the only optional constraint.

A RESTful service needs to adhere to all of the above-mentioned constraints (except Code on Demand) to be called as a RESTful API.

Having covered HTTP and REST-based services we will cover OData in my next blog.

Next Blog: What is OData? (Part-3)