Skip to Content

Introduction : SAP documentation refers that OData is RESTful but does not explain well what REST is ? The blog below is a compilation from other sources and throws some light on what is REST and provides some further links for self study.

Target audience :  SAP UI5 / Fiori Consultants

Date Published : 8th Feb 2016

Below is the common slide that comes up many times while reading up about OData in relation to SAP UI5 or Fiori.

Capture.PNG

6 Design Constraints of a RESTful Architecture


/wp-content/uploads/2016/02/ss_883402.jpg

  • Client-server architecture: The participants of a RESTful architecture must implement the client-server model, which allows for the client and server software components to be developed independently. It assumes that the client will take no part in long-term data storage and that the server will take no part in the presentation of the data it supplies. This principle is known as the Separation of Concerns.
  • Cacheability:  In order to improve performance and scalability, every server response must carry with it an indicator to denote whether or not it can be cached for future use. This is to prevent the client from working with outdated data.
  • Statelessness : The communication between participants must be stateless. A stateless interface requires the client to supply all the necessary information for the server to process the request. Session information must be held on the client side. The server can hold client state information, however, the state information must be known to, and addressable by the client.
  • Layered System : The communication between participants must be layered. When the client communicates with a server, it should not be able to distinguish whether it has communicated with the actual end-point server that will supply the requested information, or some intermediate server used for system scalability or security.
  • Uniform interface : between the clients and servers decouples the architecture. A uniform interface has the following characteristics:
    • The server must provide the client with a representation (for example a URL) of its resources.
    • A means must be provided for the client to manipulate those resources (for example provide operations such as Create, Read, Update, Delete, and so on).
    • All responses sent to the client must be self-describing.
    • The manipulation of server-side resources can only be performed by hypermedia (that is links) supplied by the server.
  • Code-On-Demand : The server is able to deliver code-on-demand to the client. At the request of the client, the server should be able to supply additional executable code to extend the client’s capabilities. This is addressed in OData by the use of function imports.

Links

http://www.odata.org/

https://en.wikipedia.org/wiki/Representational_state_transfer

http://rest.elkstein.org/

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply