Monday, April 5, 2021

REST API and its 6 constrains

👉    What is REST API?

*    REST stands for Representational State Transfer.

*    It is often used in development in web services. (designing loosely coupled applications over HTTP).

*    It specifies highlevel design guidelines and leaves the implementation to be constructed by the developer.

*    REST is an architectural design, its not either a protocol or a standard.

*    When a client request through the REST API it transfers the resource state to the endpoint or requester.

*    The response from the REST API may be a JSON, HTML, XML, PHP or even a plain text.

*    The RESTful API HTTP request contain headers and parameters which consists of important identifier information such as request metadata, authorization, Uniform Resource Identifier (URI), cookies and more.


👉    What are the architectural constraints of REST API?

*    The above diagram shows the 6 main architectural constrains of the REST API. Although it states 6 the main constraints are only 5. The last constraint (Code-on-demand) is not that visible in the industry and either used in many instances.

1.    Uniform Interface.

*    Uniform interface gives us a simple idea of having a global language which can be understood by everyone.
*    This is based on the HTTP specification.
*    The person should be able to conclude that this is a RESTful API request by looking at the URI, HTTP verb.
*    An example for a URI is https://sliit.lk/api
*    Now lets look into some examples in handling a resource in REST API.

    💥    Create a resource.    POST v1/faculties
    ðŸ’¥    Fetch a resource.    GET v1/faculties
    ðŸ’¥    Update the entire  resource.    PUT v1/faculties/{faculty.id}
    ðŸ’¥    Delete a resource.    DELETE v1/faculties

*    Now lets create a department inside a faculty.
    
    ðŸ’¥    POST v1/faculties/{faculty.id}/departments

*    From the above example what is this faculty.id?
        This is known as the route parameter. There can be multiple route parameters only if it makes a meaning. In many cases the route parameters are not numerous in an URI.

*    What are query parameters?
        These are used in sorting, pagination. These are optional in an URI. There can be multiple query parameters in an URI depending on the logic.

     ðŸ’¥    POST v1/faculties?order-by=name

2.    Stateless.

*    This constrain states that the request has to self-contained.
*    The server does not maintain the state of the client.
*    This in turn can said as, in client-server communication the client information is not stored between the get request and each request is separated and unconnected.

3.    Client-server.

*    The REST API request and response follows a client server architecture.
*    This has a client, server and a HTTP request and response.
*    The HTTP stack is the communication platform between the server and the client.

4.    Cacheable.

*    The REST services should be cacheable.
*    In general the REST services are cacheable, but according to the business requirement the caching nature changes.
*    Consider a banking system, where it is needed to store the account transaction details. But this system is non-cacheable due to security reasons.

5.    Layered System.

*    This constrain mainly hides the inner complexities from the client.
*    In simple words, the inner business logic is not shown to the end user.
*    The client only request and receive the response, in which he/she can see only the URL, not how the resource is handled according to the request.

6.    Code-on-demand [OPTIONAL].

*    This states that the server is able to transfer some code logics to the client, to execute them in the client side.
*    This is not mainly done in the industry for security and performance issues.
*    On the other hand if the code is transferred to the client, it becomes an over-head from the client and results in non-reliable nature.

    


No comments:

Post a Comment

Monolithic vs Microservices

👉     Monolithic Architecture. *     Monolithic architecture was there before Microservices came into action.  *     All functionalities or...