REST APIAround MeBlogs

A drive into the core principle of REST API

The latest trend in software architecture design is to implement REST API. This is a first step to make the “internet of things” possible. If you wonder what is internet of things then give a thought to your imaginations.

“Say you are coming back from your client meeting in a cab and you are hungry. You visit the restaurant website from your Smartphone and place the order. Your bank paid the restaurant on your consent. Mean while, you get an e-mail from your client and you need a print-out of it. So you send a request to your office printer to get it printed. Now you reached the office and pay the driver via your bank with single tap and then head towards your cubical and see both the print out and food is ready on your table “. Wow! That’s a great experience.

You had this wonderful experience because everything – your printer, bank account, and restaurant is online. They can speak to each other! This is called internet of things. You can connect the between devices, services and more seamlessly.

Now, do want your app to be part of “Internet of Things”? If your answer is YES in a corner of your mind then your app must be built on REST API. Technically REST API is a one of the means to achieve it. Using REST API, restaurant can speak to your bank and your smart phone can speak to the printer at your office.

Your API is everything for your application. It has all the business logic packed inside it. You use it for your web App, iOS App, Android App, smart watches, Google glasses and for everything which would come next in the market. Other application on the internet uses it to communicate with your application. It’s a kind of single source of truth, in fact eventually API is what defines the capability of your application. If you are thinking in the same lines, then read ahead and understand the core principles of REST.

Also read: Top 5 business benefits of private API

REST – Representational State Transfer – is a style of architecture based on a set of principles. These principles describe how things on internet are defined and accessed. So REST is the style of software architecture & not the set of standards. The architectural properties of REST have specific interaction constraints –

  1. Client-Server
  2. Stateless
  3. Uniform Interface
  4. Cacheable
  5. Layered System
  6. Code on Demand (optional)

Client-Server

Real time implementation of REST involves client-server model. The API takes the role of the server and application consuming it plays the roles of the client. Client is concerned with user interface and API is concerned with the business logic and data storage. Hence the portability of the client code is achieved, at the same time servers can be simpler & scalable.

Stateless

Like HTTP, server is stateless. The client is responsible to maintain the state and send the state information with the every request it makes. Of course, session state can be transferred by the server to another service such as a database to maintain a persistent state for a period and allow authentication. Even with this client has to send its session state identification details such as tokens for every request it makes.

Uniform Interface

This constrain happens to be the fundamental of REST. The API is a collection of resources or things of your application. They are the entities of your application in form of noun. The URL is the access point for the resources.

The representation of these resources is separate from the resource itself. Representation of resources is done in form of JSON, XML and HTML etc. A representation has a metadata which could be used by the client for modification of resource.

A different URL can access the same resource with different HTTP verbs. The action on the resource is defined based on the HTTP verbs like GET, POST, PUT, PATCH, DELETE etc. The HTTP response includes the result of the request with the HTTP codes.

Each response will have enough information about how they must be processed. This is done by defining the MIME type (internet media type) of the response.

Apart from the fixed end-point of REST API, client can interact using hypermedia provided dynamically by servers. A REST client need not have prior knowledge about how to interact with server beyond a generic understanding of hypermedia. By contrast, in a service-oriented architecture (SOA), clients and servers interact through a fixed interface shared through documentation or an interface description language (IDL).

Cacheable

It isn’t good for the client performance to ask for repetitive data every time. It can cache the response of the server and reuse it again when required. Of course this can welcome common problems with cached stale data. Hence server responses must implicitly or explicitly, define themselves as cacheable or not. If cacheable then they have to define the maximum amount of time it can be cached, after which client has to get the data again.

Layered System

Client need not know if it is connected with the server directly or there is some intermediate middleware exists in between. It need not know if it is getting data from the database or some cached data on the server is sent back as the response. It is basically separation of concern .Client has to just worry about the interface of the API and not which server responds to its request. This improves the scalability from point of server.

Code on Demand (optional)

Server can extend the capabilities of the client by transferring the executable code as a part of its response. This would help in client side validation, light-weight asynchronous sub-request etc. However, not much of the API implements this and of course, this is an optional constrain of the REST architecture.

Finally adhering to all the above constrains, REST server can achieve desirable properties such as performance, scalability, simplicity, modifiability, visibility, portability, and reliability.

  • Naveen

    HI Sachin,

    Rest is New to me and i’m a beginner as far as my understanding is concerned

    Rest is an Architecture which is used to develop webservices and webservices are programs that are used to operate between interoperable machines or programming languages

    An example would be you have products written in different programing languages but you need to establish an communication between them there comes the webservice to the rescue which is understood by every product/programming language you are trying to communicate with, to implement this we use REST ARCHITECTURE,

    And REST does the same thing of fetching data ,adding records etc but using its architectural way and it may be fast because it uses HTTP request in a raw way

    e.g GET / something
    Host : abc.com

    This happens when a request is made to a page so when we pass it in a raw way the conversion of the request to its http way may be not required and it would be fast

    I Have implemented HDFC Payment Gateway,Google Oauth Login , Facebook login etc so whether i can assume i have used rest apis but not written one

    Am i right please suggest me if i’m wrong, just trying to understand what it is, my understanding of the whole concept may be wrong bear with i’m new to it waiting for your reply eagerly (Member of PHP MeetUp)

    • http://sachinkulkarni.info/ Sachin G Kulkarni

      Hi Naveen,

      Your basic understanding of REST API is correct. As you have implemented REST API like Google Oauth Login , Facebook login etc , you can say you have consumed the REST API . But have not built one.

      Further, you should note that, REST API is a architectural style of implementation. It is not a protocol like SOAP. Implementing developer friendly REST API is a real challenge…

      “Please introduce yourself in the comments. I would like to know more about you!”

      • Naveen

        Thanks For the Reply Sachin,

        I’m a PHP Developer , I love to learn and implement technologies that would enhance user experience, I had built my OWN CMS using plain procedural code within 3 to 4 days but later on realized that reinventing the wheel would be a waste of time and have moved to wordpress , currently learning wordpress and codeigniter and OOPS in PHP if any guidance you could provide me to learn OOPS in PHP,wordpress and codeigniter that would be grateful finally i have fallen in love with PHP Programming

        • http://sachinkulkarni.info/ Sachin G Kulkarni

          Nice to hear your CMS story and realization about reinventing the wheel.

          Hopefully, you need to move few steps ahead of codeigniter. Start using more serious framework such as laravel/symfony. Make use of tools like composer, scaffolding etc.

          • Naveen

            Thanks Buddy I will check out
            Symfony or laravel??? oops in php ???

  • Girijesh

    codeigniter vs symfony. Which is more powerful?

    • http://sachinkulkarni.info/ Sachin G Kulkarni

      Girijesh,

      I would say symfony is industry standard for large projects. However for smaller projects I would still prefer codeigniter.Of course, symfony is very powerful when compared to codeigniter.

      Below is the link to one of my article which discuss about the same. Please have a look into it.

      http://www.sachingkulkarni.com/php-framework-days/