REST stands for Representational State Transfer. Just like there is architectural style in buildings, there is architectural style in software design as well. REST is type of software architectural style. The style defines the characteristics. REST contains a set of constraints that would be found within a protocol, specifically the HTTP protocol. It is the architecture of the internet, as we know it today. REST is a simple way to organize interactions between independent systems. It is the foundation to many popular APIs in use today. REST requires very little overhead, which one of the reasons that it has grown in popularity. REST treats objects on the server-side, as in rows in a database table, as resources that can be created or destroyed. A RESTful API comes down to four essential operations:
o Receiving new data
o Creating new data
o Updating new data
o Deleting data
Each operation uses its own HTTP method, and each of these manage the data:
o GET – getting
o POST – creation
o PUT – update or modify
o DELETE – removal
REST is resource-based. When discussing REST, generally nouns would be used to describe things or resources, rather than actions. Resources are defined by URIs in each request. A URI can refer to a resource. Multiple URIs may point to the same resources. The representations are separate from the resources themselves. The representation is not a resource.
When describing REST, you must also describe representations. The representation part of the resource state is how the resources are manipulated in a REST system. Representations are transferred from between client and server. The representation contains enough information to modify or delete information on the server. Representations are typically in JSON or XML format. A Person resource would be Kelley. The Service would be the contact information accessed by a GET command. The representation would be the contact record (name, address, phone#) for Kelley in JSON or XML format. This information would be transferred between the client and the server.
A constraint is defined as “something that the design of the particular object MUST have and must be included in the final design.” (Answers.com) There are six constraints applied to REST architecture. Violating any of the constraints, with the exception of the Code on Demand constraint means that the service is not strictly RESTful.
The first constraint is Client-Server. This constraint always keeps everything separate. In essence, this is a disconnected system. The uniform interface, HTTP, is the link between the Client and the Server. Because the storage device is resident on the server-side, portability across platforms is improved. Most importantly, the separation allows the components for expand independently, “thus supporting the Internet-scale requirement of multiple organizational domains.” (Fielding, 2000)
A stateless interaction is the next constraint. Stated another way, every server can service any client at any time, there is no session sticky sessions. The session information is stored on the client and then only passed to the server when needed. The client’s application state is never be stored. Instead, it should be passed around from the client to ever place that needs it. This is where the “ST” in REST comes from, State Transfer. The state is transferred around instead of having the server store it. The HTTP protocol was designed to operate in a stateless capacity.
The properties of visibility, reliability, and scalability become important with this constraint. Visibility is improved because one request is all that is needed in order to derive the type of request. Reliability is improved because failure recovery is improved. In a RESTful system, the server does not have to store state between requests. This allows the server to release resources in a timely manner, which improves scalability. The disadvantage is that performance could be adversely affected due to the repetitive data transfer caused by not storing the data on the server.
Cache constraints may be used. This enables response data to be marked as cacheable or not-cacheable. Cacheable data may be reused as the response to the same subsequent request. The data must be labelled:
Implicitly – not denoted
Explicitly – server specifies
Negotiated – Client-server negotiates how long the data can be cached
Adding cache constraints could partially or completely remove interactions and improve efficiency and scalability by reducing the time that communications have to wait.
Another constraint is that single uniform interface that all components must interact through. This makes interaction with other services simpler. This also means that implementation changes can be made in isolation. These changes do not affect component interaction since the uniform interface is always unchanged. REST prohibits a specific service from changing the interface an optimization could be provided. This constraint is based upon three important elements:
▪ resource identifier syntax – How can we express where is the data being transferred to or from?
▪ methods – What are the protocol mechanisms used to transfer the data?
▪ media types – What type of data is being transferred?
The REST service capabilities are exposed using these individual services. This type of service contract is made “uniform” by the fact that a master set of these elements is defined for use by a collection of services. This allows standardized baseline elements of the service contract.
The next constraint, the layered system, adds middleware components. These components can exist as services or service agents. Specifically, a layered system requires that this middleware be inserted transparently so that interaction between a service and consumer is consistent. This happens whether the consumer is communicating with a service residing in a middleware layer or a service that represents the receiver of a message. A service does not need to be aware of whether its consumer is further communications with other services, or where the consumer itself is acting as a service for other consumer programs. Within this constraint, no layer looks beyond itself. Layers can be consumers, services or middleware components. Logic within a solution layer cannot have knowledge beyond the immediate layers above or below it.
The Sixth constraint is an optional constraint. Code-On-Demand is primarily intended to allow logic within clients, such as web browsers, to be updated independently from server-side logic. Code-on-Demand typically relies on the use of Web-based technologies, such as web browser plug-ins, applets, or client-side scripting languages, like JavaScript. Code-on-Demand can also be used to support the stateless constraint. It can also delay the processing effort. This constraint may be justified when service logic can be executed by the consumer more efficiently or effectively. Architectures that do not use Code-on-Demand can still be considered RESTful since this is an optional constraint.
Violating any of the constraints other than the Code-On-Demand command means the service is not strictly RESTful. An example of this would be Three-legged OAUTH2. Compliance with REST constraints has several benefits, such as Performance, Scalability, Simplicity, Modifiability, Visibility, Portability and Reliability. REST supports the Performance goal by using caches to keep available data close to where it is being processed. REST keeps the interactions simple. The goal of a REST system is to keep the load balanced through the use of the Layerered System and through Uniform Contract constraints. Because the Stateless constraint designs interactions to be request-response pairs, the system is simplied because the services can be handled autonomously. The session data is contained in each request. Simplicity is a focus for REST because it impacts how services are defined, discovered, and eventually used (or reused) and further determines how easily services can be evolved independently. Simplicity is most improved through the Uniform Contract constraint. With this constraint, each service’s capabilities are available through an interface that is generic. This simplifies the cross-service technology architecture because services and consumers do not have to contend with individually-defined technical interfaces. Modifiability in a REST-style architecture is further broken down into the following areas:
▪ evolvability – the ability to refactor and redeploy a service, consumer, or middleware component without impacting other parts of the architecture (even when the upgrade occurs while applications are running)
▪ extensibility – the ability to add functionality to the architecture (even while solutions are running)
▪ customizability – the ability to temporarily modify parts of a solution to perform special types of tasks
▪ configurability – the ability to permanently modify parts of an architecture
▪ reusability – the ability to add new solutions to an architecture that reuse existing services, middleware, methods, and media types, without modification
The best way to summarize a true description of REST is to quote the author of the system itself: “A better way to think of the problem is to work backwards from the
end result. What do you want the state of the system to be at the completion of N requests (potentially parallel, multiple clients)? Hint: A RESTful system progresses from one steady-state to the next, and each such steady-state is both a potential start-state and a potential end-state. I.e., a RESTful system is an unknown number of components obeying a simple set of rules such that they are always either at REST or transitioning from one RESTful state to another RESTful state. Each state can be completely understood by the representation(s) it contains and the set of transitions that it provides, with the transitions limited to a uniform set of actions to be understandable. The system may be a complex state diagram, but each user agent is only able to see one state at a time (the current steady-state) and thus each state is simple and can be analyzed independently.” (Fielding, 2006)