Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 
Product and Topic Expert
Product and Topic Expert

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)

Product and Topic Expert
Product and Topic Expert
0 Kudos

Hi All,

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


Thank you.

Active Participant
0 Kudos

Nice Documentation Anubhav ,

Very useful information for any new comers...

Thanks ,


helpful and clear, thanks!
Very Helpful, thanks