REST

What is REST?

REST stands for Representational State Transfer. it had been designed by computer scientist Roy Fielding.

REST is a set of rules that are followed when creating an API that determines what the API seems like. Web services that follow the REST architectural style are called RESTful web services. It allows request systems to access and manipulate web resources using a uniform and predefined set of rules. REST-based systems interact through the Internet’s Hypertext Transfer Protocol (HTTP).

REST requires the client to make an HTTP request to retrieve or modify the data.

How does the Request look like?

The Request contains,

• HTTP Verb/Method: which defines what kind of operation to perform

• Endpoint: URL where the rest Server is listening or a path to a resource

• Header: the extra details provided for communication between client and server like host accept-language etc.

• Data: An optional messages body containing the data to be sent to the server

HTTP Verbs/methods

There are 4 basic HTTP verbs we use in requests to interact with resources during a REST system:

• GET: retrieve a selected resource or a set of resources

• POST: create a new resource

• PUT: update a selected resource

• DELETE: remove an existing specific resource by id

The REST is resource-based. Identify by URIs. Multiple URIs can refer to the same resource but vary depending on the HTTP verb.

The REST architecture describes Six Constraints for the REST API. These 6 constraints should be followed for a service to be RESTful.

1. Client-Server: This constraint basically means that the server application and the client application can evolve separately without interdependence. The client sends the request to the webserver. The server can reject the request or accept and respond to the request.
2. Stateless: One client can send multiple requests to the server and each request is independent. The server will treat every request as new. Each request should contain all the required information so that the server can process it accordingly and respond to the client. The server does not keep any information about the client state. State information must stay on a client such as sessions.
3. Cacheable: The client may requesting the same resources several times, the Server has to respond to the same client with the same response. It can lead to unnecessary processing and significantly reduce performance. The cacheable concept is using to avoid that. So if the client makes the same request instead of going to the server, it goes to the cache and gets the required information.
4. Layered System: A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way. By allowing load balancing and having shared caches, intermediary servers will increase device scalability. Protection protocols may also be enforced by layers.
5. Uniform Interface: This is a key constraint that differentiates between a REST API and a Non-REST API. It suggests that there should be a uniform way of interacting with a given server irrespective of device or type of application such as website, mobile app.
6. Code on-demand: This is the only optional constraint. This condition allows the client to run some code on demand, that is, extend part of server logic to the client, either through an applet or scripts. Thus, different customers may behave in specific ways even using exactly the same services provided by the server.