What is REST?

What is REST, or what we also know as REST API. We explain what features are found in this type of application and why they are so widely used on the Internet today, what problems they manage to solve and how they work.

REST APIs are really all the rage these days: it seems like any application has to provide its “REST API”. But… what does a REST API really mean?

REST derives from “REpresentational State Transfer”, which translated would be “state representation transfer”, which does not clarify much, but contains the key to what it means. Because the key to REST is that a REST service is stateless, which means that, between any two calls, the service loses all its data. That is, you cannot call a REST service and pass it some data (for example, a username and a password) and expect it to “remember us” in the next request.

Hence the name: the state is maintained by the client and therefore it is the client that must pass the state on each call. If I want a REST service to remember me, I have to pass it who I am on every call. That can be a username and password, a token, or any other type of credentials, but I have to pass them on every call. And the same applies to the rest of the information.

Being stateless is a clear drawback: having to pass state on each call is tedious to say the least, but the tradeoff is clear: scalability. To maintain a state requires some place (usually memory) to store all the states of all the clients. The more clients, the more memory, until in the end we can end up not being able to admit more clients, not because of a lack of CPU, but of memory. It is something similar to what happens with the traditional web (which is also stateless). Whatever the technology with which you develop for the web, you surely know that you can create what is called a “session”. Session data is maintained between requests and is per user. The classic example of a session can be a shopping cart, among the different web requests, the shopping cart information is maintained (be careful! there are other alternatives to implement shopping carts).

As a rule, the session is stored in the server’s RAM, so it’s easy to run out of memory if we put too much data into the session (or have many concurrent users). Of course, we can use multiple servers, but as web developers know, moving the in-memory session between servers is generally impossible or highly inefficient, which penalizes load balancing, which in turn results in less scalability and less Fault tolerance. There are intermediate solutions, such as saving the session to the database, but their impact on performance is usually very large. In fact, the main advice for developing highly scalable web applications is: don’t use the session.

So, we have that being stateless is the main feature of REST, although of course not the only one. Thus, any REST service (if it wants to be worthy of the name) should be stateless, but not every stateless service is RESTful. There are other factors, but we are going to highlight what the English call “uniform interface” and it is what differentiates a classic web service (RPC-oriented) from a REST service.

SOAP and REST

SOAP is the acronym for “Simple Object Access Protocol” and is the protocol behind the technology that we commonly call “Web Services” or web services. SOAP is an extraordinarily complex protocol designed to provide solutions to almost any communication need, including advanced aspects of security, transactionality, secured messaging, and more. When SOAP came out, it was a golden age of web services. Although the first implementations were what were called WS1.0 and supported almost no advanced scenarios, everyone paid the price for using SOAP, as it seemed clear that it was the standard that would dominate the future. Over time, WS-* specifications came out that provided advanced solutions, but as SOAP capabilities grew, so did its complexity. In the end, SOAP web services end up being a juggernaut with many capabilities but in most cases we don’t need.

For its part, REST is simple. REST does not want to provide solutions for everything and therefore we do not pay too much complexity for power that we may not need.

Uniform interface

A fundamental difference between a classic web service (SOAP) and a REST service is that the former is RPC-oriented, that is, to invoke methods on a remote service, while the latter is resource-oriented. That is, we operate on resources, not on services.

In a REST API the idea of ​​”service” as such disappears. What we have are resources, accessible by identifiers (URIs). We can perform actions on these resources, generally differentiated through different HTTP verbs.

Thus, in a classic web service (SOAP) we would have a service called BeerService that would have a method called GetAll that would return all the beers. The idea, regardless of the technology used to consume the web service, is that a method (GetAll) of a remote service (BeerService) is called. In the same way, to obtain a specific beer, we would call the GetById() method, passing it the id of the beer. Hence, it is said that they are oriented to RPC (Remote Procedure Call – Remote method call).

For its part, in a REST service the very idea of ​​a service vanishes. Instead we are left with the idea of ​​a “resource”, let’s call it a “Collection of Beers” that has a URI that identifies it, e.g. eg /Beers. Thus, if I invoke said URI I must obtain a representation of said resource, that is, I must obtain the list of all the beers.

To get data for a beer, there will be another resource (beer) with an associated URI. In addition, there are relationships between the resources: it is clear that a beer is part of the “Collection of beers” so it seems logical that from the entire collection (/Beers) you can access one of its elements with a URI of the type /Beers /123, where “123” is the beer ID.

Let’s go back to our SOAP service: to register a beer we would call an “AddBeer” method of our “BeerService”, and we would pass the beer to add. On the other hand, in our REST API adding a beer consists of using the URI of said beer, (eg /Beers/456 if we are adding the beer with ID 456) using POST or PUT as HTTP verb and placing the data of the beer in the request body. The URI to access the beer with ID 456 is always /Beers/456 and it is the HTTP verb (GET, POST, PUT, DELETE,…) that indicates the operation we want to do with that beer.

HTTP methods in REST

In a REST API we use the HTTP methods, which have always existed in the protocol although up to now they have been underused in classic websites (those based on content), to indicate the type of operation that we are going to perform on the resources that the services offer us. Web.

These methods are also known as HTTP verbs and are the following:

• GET: For data query operations. You can consult a list of beers or consult a specific beer. Both operations would be GET, except that the query to the list would be made on the resource /beer and the query to a beer on the resource of a particular beer /beer/33 or something similar.
• POST: Insert operations
• PUT: To make changes
• PATCH: To make partial modifications to a resource
• DELETE: To delete a given resource.

In this way, the same URL, or endpoint, such as /beer/77 can be used to perform multiple operations, it all depends on the HTTP request method that we are using.

As you have seen, API REST web services are capable of performing the typical operations of a CRUD.

REST or just API, or web service

Many times the term REST or REST API is used to refer to what we know as a web service, but not all web services are RESTful.

REST is a whole pattern of behavior that we can support in a more or less faithful way. Not all APIs are RESTful and this may not be a problem either. Behaving more or less close to the REST pattern means that the clients that are going to use that API may have fewer surprises, but sometimes it can also be a bit limiting and developers can take licenses in the implementation of their web services.

Public REST API

There are dozens of REST APIs or public web services, which you could use to carry out all kinds of tests and develop sample frontend applications, to learn a framework or simply to know how these types of backend applications behave.

If you want to access an interesting list, we recommend this collection with the .