REST is not a standard; it simply defines the principles of architecture to implement network applications or services. However, the implementation of REST is based on standards: HTTP, XML, etc. These are the features of REST services:

REST services must be based on a Client-Server architecture. A server that includes the resources and conditions, and clients who access them

No condition
REST Services can be scaled to achieve high performance to span the demand from all possible clients. This requires server farms to be implemented with charge balance and failover or different server levels to minimize the response time for the clients. Since intermediate servers are used, the REST clients are required to send full and independent information with each resource condition request. This enables intermediate servers to exchange information about client sessions.

A full and independent request does not require the server, while processing the request, to store any context or session. A rest client must include in the HTTP header and body all parameters, context and data necessary for the server to generate the answer. This increases the performance of the REST service and simplifies the server design and implementation since the lack of client sessions removes the need to synchronize session data with external applications.

Cache-enabled information
In order to improve network traffic efficiency, the answers from the server should be cache-enabled. This information is used by REST clients to decide whether they perform a local copy of the resource including time and date of the latest resource condition change. In such a case, the client requests the resource condition so, if the condition remains unchanged, the server answers only with a very short message indicating that it has not changed. This allows the network traffic to be optimized.

  • Facebook
  • Twitter
  • Google+
  • LinkedIn

Consistent interface
One of the main features 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 as follows:
– GET: collects information from a resource
– PUT: modifies or updates the condition of a resource
– POST: creates a new resource in the server
– DELETE: removes a resource of the server

Usually, a URL in a HTTP GET request identifies a resource. For example, the following request asks about the condition of a resource called “SensorHumedad_001” in the sensor catalog of MiEmpresa:

Another way to request information to a server consists of building a URL which includes parameters that define the search criteria in the server to find the requested resources:

  • Facebook
  • Twitter
  • Google+
  • LinkedIn

A resource is a logical URL, not a physical one. This means that a HTML page is not needed in the server for each sensor. With a POST method a new resource would be generated in the server as a logical URL.

The way the server handles the client requests must be hidden for these. A client must not know the programming language used by the server nor how it generates information; it should know simply the way to access information. This enables migration from one server to another, from a language to another, with no need to make changes in the existing clients.

The principles defined by REST differentiate the GET method from other choices because changes should not affect the information in the server. The PUT, POST and DELETE methods modify a resource, but GET only collects information and never modifies the resource.

Resource access by name
A REST system is made of resources accessed via URL, and these must be intuitive, predictive and easy to understand and set. A way to achieve this is by means of a hierarchical structure, similar to directories. It could be a unique root node from which the subdirectories are created to expose the main services areas, until they shape a tree with the resource information.

The access to resources is made as a composition of an 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 include calls to features which run code in the server, so they should not be file addresses that run actions (pages with .jsp, .php, .asp extensions.)

Related resources
The resources available in the server are usually interrelated. As a consequence, the condition information of a resource should allow access to other resources. This is achieved by adding in links or URLs from other resources to the condition of resources. For example, a resource which condition identifies sensor of a specific kind can be requested:

The server could return the list of all sensors of that type, and the condition information can include a link to each of these sensors, adding the drill-down capacity to access all details. The answer of the server to the previous request may be similar to the following:
{Id}SensorHumedad_001 {Detalle}
{Id}SensorHumedad_002 {Detalle}
{Id}SensorHumedad_003 {Detalle}
{Id}SensorHumedad_004 {Detalle}

  • Facebook
  • Twitter
  • Google+
  • LinkedIn

A good practice in REST services is not displaying all the resource information in a request, but displaying the information gradually. This allows the network use to be minimized if the client does not need many details about a specific resource. This can be achieved including links in the resource condition; these links are other resources with further details.

Answer in a known format
The representation of a resource reflects its current condition and its attributes when the client has made the request. The result can represent simply the value of a variable on a certain time, a database register or other type of information. In either case, the information must be delivered to the client on a format understandable for both parts, and included in the HTTP body. This content must be simple and understandable by a human and, of course, translatable by an application. This allows the REST service to be used by different clients, regardless of the programming language.

The most usual formats are JSON (JavaScript Object Notation) and XML (Extensible Markup Language), and others like CSV (Comma Separated Values) are also accepted. Each format has advantages and drawbacks. Since JSON was designed for JavaScript, its translation is very straight in this environment. XML is easy to expand and reduce since the information is nestled and its format is widely known. By the other hand, CSV is a compact format.

In REST services, due to the different types of clients that can exist, the implementation is not recommended to return the condition of a resource in only one format. This can be achieved in different ways, for example by creating in the server a different URL for each format, or writing a parameter in the same URL of the translator server. Both options are provided below:

Share This