Skip to Content
Author's profile photo Anubhav Pandey

OData – Everything that you need to know (Part 2)

In my previous blog, I discussed about how 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:

OData – Everything that you need to know (Part 1)

What is REST?

REST or REpresentational State Transfer is an architectural style that uses 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, 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 the 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 in mostly JSON or XML format. Client will typically have enough information to manipulate the resource on the server.  For example, if Person is modelled 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

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 pass 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 connects to the Resources.

4. Cacheable

Another constraint on a RESTful API is that any response that is coming from the Sever 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 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 need not 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 Server can transfer logic to the client as 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: OData – Everything that you need to know (Part 3)

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Anubhav Pandey
      Anubhav Pandey
      Blog Post Author

      Hi All,

      I have added few more blogs to this series to demonstrate building an OData service.

      Author's profile photo vamsilakshman p
      vamsilakshman p

      Nice Documentation Anubhav ,

      Very useful information for any new comers...

      Thanks ,


      Author's profile photo Ashok Babu Kumili
      Ashok Babu Kumili

      Thank you.

      Author's profile photo Nadia de Venezia
      Nadia de Venezia

      helpful and clear, thanks!

      Author's profile photo Edwin Ballesteros
      Edwin Ballesteros

      Very Helpful, thanks