REST API
The term REST (Representational State Transfer) originated in 2000, described in the thesis of Roy Fielding, father of the HTTP specification. A REST service is not a software architecture but a set of restrictions that must TAKE into account in the software architecture that we will use to create web applications respecting HTTP.
According to Fielding, the restrictions that define a RESTful system would be:
- Client-server: The server controls the data while the client is in charge of managing user interactions. This restriction keeps the client and the server loosely coupled (the client does not need to know the details of the server’s implementation, and the server “doesn’t care” about how the data it sends to the client is used).
- Stateless: here, we say that each request that the server receives should be independent and contain everything necessary to be processed.
- Cacheable: Must support a caching system. This storage will avoid repeating several connections between the server and the client to recover the same resource.
- Uniform interface: defines a generic interface to manage each interaction between the client and the server in a uniform way, which simplifies and separates the architecture. This restriction indicates that each REST service resource must have a unique address or “URI”.
- Layer system: the server can have several layers for its implementation. This helps improve scalability, performance, and security.
Today most companies use REST API to create web services. This is because it is a logical and efficient standard. For example, we have the Facebook identification systems or the authentication in Google services (spreadsheets, Google Analytics, Google Maps, …).
Methods in a REST API
The most critical operations that will allow us to manipulate resources are:
- GET is used to retrieve a resource.
- POST is used most of the time to create a new resource. You can also use it to send data to an existing resource for processing. In this second case, it would make no further aid.
- PUT helps create or edit a resource. The full representation of the appeal will be in the body of the petition. If it exists, it is replaced. Otherwise, a new resource is created.
- PATCH performs partial updates. Changes to be made to the resource will be included in the body of the request. It can be more efficient in using the network than PUT since it does not send real help.
- DELETE is used to delete a resource.
Other less common but also special operations are:
- HEAD works the same as getting but does not retrieve the resource. It is used above all to test if the resource exists before making the GET request to obtain it (an example of its use would be to check if there is a large file or resource and to know the response that we would receive from the REST API before proceeding to the resource download).
- OPTIONS allows the client to know the possibilities or requirements associated with a resource before initiating any request about it.
Two terms to keep in mind are safe methods and idempotent methods. Secure methods are said to be those that do not modify resources (they would be GET, HEAD and OPTIONS), while idempotent methods would be those that can be called multiple times, obtaining the same result (GET, PUT, DELETE, HEAD and OPTIONS).
Idempotency is very important as it allows the API to be fault-tolerant. For example, we can perform a PUT operation to edit a resource in a well-designed REST API. If we get a Timeout failure (the request-response timeout has been exceeded), we would not know if the resource was created or updated. As PUT is idempotent, we do not have to worry about checking its status since, if the help has been completed, a new PUT request will not create another one, something that could have happened with an operation such as POST.
Some characteristics of a REST API
- The use of Hypermedia (procedures to create content containing text, image, video, audio and other information methods) to allow the user to navigate through the different resources of a REST API through HTML links (HATEOAS principle, Hypermedia as the engine of application state or Hypermedia as the application state engine).
- Language independence: The layering of the API allows the client to disregard the language in which the server is implemented. It is enough for both of them to know that they will receive the responses in the interchange language used (XML or JSON).
- URI identifies resources in a REST API: That same URI will allow access to the resource or perform any modification operation on it.
- The APIs should handle any errors that occur, returning the appropriate error information to the client. For example, in the case of a GET request on a non-existent resource, the API would return an HTTP 404 error code.
We can implement our APIs with JAX-RS and Spring Boot for Java, Django REST framework for Python, Laravel for PHP, Rails for Ruby or Restify for Node.js.
Also Read: Five Advantages Of Modern Data Protection