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 –
- Client-Server
- Stateless
- Uniform Interface
- Cacheable
- Layered System
- 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.
7 comments for “A drive into the core principle of REST API”