What is REST API?

REST is an architectural style for building APIs.RESTful is an API state that whenever called, transfers the server to the client i.e. to the state of a requested resource. REST stands for REpresentational State Transfer and is used to implement web services. It is one of the prominent ways to send data over HTTP. REST is not a protocol or HTTP, it just aims to use HTTP properly.

To truly understand REST you must know the 2 key terms Client & Resource – The client is the one who uses the API e.g. a developer can use this to do any set of specified tasks. A resource could be an object that provides information about the request created.

The main aim with which REST is created, is to deliver a well-designed web application that yields requested results from the architecture.

A brief REST vs SOAP

Simple Object Access Protocol (SOAP) is a different approach to invoke web services. While REST is an architectural style, SOAP is a communication protocol for XML_based message exchange. REST API’s can use SOAP.

REST its Constraints

In order for an API to be RESTful and to achieve the desired system optimisation, it has to adhere to 6 constraints.

• Client — server separation
• Stateless
• Layered system
• Uniform interface
• Cacheable
• Code-on-demand

 

1. Client-Server

 

Clients and Servers act independently and the interaction between them takes place in form requests only. Clients initiates request and servers react to these initiated requests

2. Stateless

Stateless means the server does not concerns over who uses the API or if a request is been sent for the same or not. A request contains  information for the server regardless of the number of times or information for the API itself.−

3. Layered system

You know it is not necessarily elementary between a client’s request and it reaching a server.There could be a number of servers in the middle for security, caching, load balancing etc., the number of layers does not affect the response time or requests reaching the server.

4. Cache

Cache makes sure that just because it has access to a server it does not overwhelm or exploit it with requests. When a client requests data, server sends it back with a version number that lets the client know if the information can be cached or not so that you don’t form the same requests often.

5. Uniform Interface

To have an effective cache, components must communicate through an uniform interface to maintain a standard payload.

The request to the server includes a resource identifier.

The response from the server returns (resource) information that the client can manipulate.

Hypermedia – A server can respond using HTTPs or descriptive state messages in addition to the request resources.

6. Code on-demand

An additional constraint, that provides code from the server. The code might be in script form or a HTML reponse which can be used or executed.

Conclusion

A good design is not one’s easy on the eyes but a designer who understands the Internet and its underlying architecture that can be optimised and relentlessly serves over time.