Jan 13, 2018

[1] RESTful web services

REST stands for REpresentational State Transfer, and in one sentence I would say that REST is an architectural style. So it is not a thing, we can't point at it, what we can do is check if a particular system follows RESTful rules and principles.

REST was defined first in Roy Fielding's doctoral dissertation and it "(...)has been used to guide the design and development of the architecture for the modern Web"(1). It is resource based, which means in REST we talk about things or resources that we identify through the URI (Uniform Resource Identifier). Resources have representations, but they are not the same, the representation is not the resource itself. The representation is how the resource gets manipulated, and consists of data and metadata which is in the form of name-value pairs. Those representations are transferred between client and server usually in JSON or XML.

To have a RESTful system it has to follow a set of six constraints. Those constraints are applied to the architecture in order to  allow scalability, simplicity, modifiability, visibility, portability, reliability and maintainability.

The first constraint is Uniform Interface, which defines the interface between client and server. This is central to REST architectural style and helps improve the visibility of the interactions. Another advantage is that it decouples and simplifies the architecture. There is one trade-off, and that is that uniform interface degrades efficiency. This happens because the information is transferred in a standardised form, rather than a specific one. "The REST interface is designed to be efficient for large-grain hypermedia data transfer, optimising for the common case of the Web, but resulting in an interface that is not optimal for other forms of architectural interaction"(2). The four guiding principles to have a uniform interface are that it is resource-based, resources are manipulated through representations, messages are self-descriptive and Hypermedia As The Engine Of Application State (HATEOAS).

The second constraint is Statelessness, this means that the server contains no client state. This is because each request is self-descriptive, so it contains enough context to process the message. Any session state is held on the client. This constraint helps us achieve visibility, reliability and scalability but it also comes with the trade-off that it may decrease network performance. This is due to the fact that repetitive data is increased.

Client-server is the third constraint. A disconnected system with separation of concerns has to be assumed. Separating the user interface and data storage concerns allows for easier portability across platforms and scalability. Also the components can evolve independently.

Another constraint in RESTful architectures is that they must be Cacheable. This is in order to improve network efficiency. Server responses (or representations) must be explicitly or implicitly labeled as either cacheable or non-cacheable. Cacheable data allows the client to reuse the information in a particular response, and this eliminates some future interactions and improves efficiency.

The Layered System constraint "(...)allows an architecture to be composed of hierarchical layers by constraining component behaviour such that each component cannot "see" beyond the immediate layer with which they are interacting"(3). Clients can't assume direct connection to the server, the information being retrieved can be cached. This improves scalability.

The sixth constraint is the only optional one. Optional constraint seem to be two contradictory words but, "An optional constraint allows us to design an architecture that supports the desired behaviour in the general case, but with the understanding that it may be disabled within some contexts"(4). The Code on demand constraint means that the server can temporarily extend a client by transferring logic to the client as a representation. This allows the client to execute this logic.

Violating any of this constraints means that the service is not strictly RESTful.



To read more: 

No comments:

Post a Comment