Characteristics of REST Services

REST is not a standard, it simply defines a set of architectural principles to follow in order to implement applications or network services. However, REST is based on standards for its implementation: HTTP, XML, etc. REST services have the following characteristics:

Client-Server
REST services must be based on a Client-Server architecture. A server that contains the resources and their states, and clients that access them.

Stateless
REST Services can be scaled to achieve high performance to meet the demand of all possible clients. This implies that it is necessary to create server farms with load balancing and failover or different levels of servers to minimize the response time to clients. When using intermediate servers, it is necessary for REST clients to send complete and independent information in each request for the state of a resource. In this way, intermediate servers can forward, route, balance without the need for servers to exchange client session information.
A complete and independent request does not require the server, while processing the request, to store any type of context or session. A REST client must include within the HTTP header and body all the parameters, context and data necessary for the server to generate the response. This increases the performance of the REST service and simplifies the design and implementation of the server since the absence of client sessions eliminates the need to synchronize session data with external applications.

Cacheable information
To improve efficiency in network traffic, server responses should have the possibility of being marked as cacheable. This information is used by REST clients to decide whether to make a local copy of the resource with the date and time of the last state change of the resource. In such a case, the client makes requests for the state of the resource in such a way that, if the state has not changed, the server only responds with a very small message indicating that it has not changed. This allows optimizing network traffic.

Uniform interface
One of the main characteristics of REST Web services is the explicit use of HTTP (HyperText Transfer Protocol) methods. These methods are indicated in the HTTP header by the client and are the following:
• GET: retrieves information from a resource
• PUT: modifies or updates the state of a resource
• POST: creates a new resource on the server
• DELETE: deletes a resource from the server.
Usually a URL in an HTTP GET request identifies a resource. For example, the following request would be requesting the status of a resource called “SensorHumedad_001” within the sensor catalog of MiEmpresa:
http://www.MiEmpresa.com/Sensores/SensorHumedad_001

Another way to request information from a server is by constructing a URL that includes parameters that define the search criteria on the server so that it can find the requested resources:
http://www.MiEmpresa.com/Sensores?Tipo=humedad&id=001

A resource is a logical URL, not a physical one. Thus, it is not necessary for an HTML page to exist on the server for each of the sensors. With a POST method, the new resource would be generated on the server, which would be accessible as a logical URL.

The way in which the server handles client requests must be hidden from them. A client should not know the programming language used on the server or how it is generating the information; it should simply know how to access the information. This allows migrating from one server to another, from one language to another without having to make changes to existing clients.

In the principles defined by REST, the GET method is differentiated from the others since it should not have effects of change in the information contained in the server. The PUT, POST and DELETE methods modify a resource, but the GET should only collect information, never modify the resource.

Access to resources by name
A REST system is composed of resources that are accessed through URLs, and these must be intuitive, predictable and easy to understand and compose. One way to achieve this is through a hierarchical structure, similar to directories. There can be a single root node, from which the subdirectories that expose the main areas of the services are created, until forming a tree with the information of the resources.
Access to resources is done as a composition of a URL that identifies the resource, and it must be the same even if the implementation on the server is modified. The composed URL should not contain calls to functions that execute code on the server, so they should not be file addresses that execute actions (pages with extension .jsp, .php, .asp).

Related resources
The resources accessible on the server are usually related to each other. Therefore, the status information of a resource should allow access to other resources. This is achieved by adding links or URLs of other resources in the status of the resources. For example, you could request a resource whose status identifies the sensors of a certain type:
http://www.MiEmpresa.com/Sensores?Tipo=humedad
The server could return the list of all sensors of that type, and within the status information you can include a link to each of the sensors, adding a Drill-down capability to access the maximum detail. The server’s response to the previous request could be similar to this:
{Id}SensorHumedad_001 {Detalle}http://www.MiEmpresa.com/Sensores/SensorHumedad_001
{Id}SensorHumedad_002 {Detalle}http://www.MiEmpresa.com/Sensores/SensorHumedad_002
{Id}SensorHumedad_003 {Detalle}http://www.MiEmpresa.com/Sensores/SensorHumedad_003
{Id}SensorHumedad_004 {Detalle}http://www.MiEmpresa.com/Sensores/SensorHumedad_004

A good practice in REST services is not to show all the status information of a resource in a request, but to show the information gradually. This allows minimizing the use of the network if the client does not need many details of a certain resource. This can be achieved by including links in the status of the resource, these links being other resources with a higher level of detail.

Response in a known format
The representation of a resource reflects its current state and attributes at the time the client made the request. This result can simply represent the value of a variable at a point in time, a record from a Database, or any other type of information. In any case, the information must be delivered to the client in a format understandable to both parties and contained within the HTTP body. This content must be simple and compressible by a human and, of course, interpretable by an application. This allows the REST service to be used by different clients regardless of the language with which they have been programmed.

The most common formats are JSON (JavaScript Object Notation) and XML (Extensible Markup Language), although others are accepted, such as CSV (Comma Separated Values). Each format has its advantages and disadvantages. Since JSON was designed for JavaScript, its interpretation is very direct in this environment. XML is easy to expand and contract since the information is nested; in addition, it is a well-known format. CSV, on the other hand, is a compact format.

In REST services, since there can be different types of clients, it is not advisable to implement a server that returns the status of a resource in a single format. This can be achieved in different ways, such as creating a different URL on the server for each format, or writing a parameter in the same URL that the server interprets. Below are both options:
http://www.MiEmpresa.com/Sensores/xml/Sensor001
http://www.MiEmpresa.com/Sensores/Sensor001?Output=xml