Representational State Transfer
Representational State Transfer ( REST with the acronym, more rarely also ReST ) refers to a programming paradigm for Web applications. There is no explicit standard, so go the ideas of what is REST, apart. Basically, REST refers to the idea that a URL exactly one page contents as a result of a server-side action (such as displaying a hit list after a search ) is, as already provided for in the Internet standard HTTP for static content ( permalinks ); a goal that sometimes, however, requires additional effort for dynamically generated pages.
History
REST comes from the dissertation by Roy Fielding in 2000, in which he responds to certain properties of the mechanisms and protocols used (eg HTTP) returns the success of the World Wide Web. Fielding was previously involved in the specification of the hypertext transfer protocol ( HTTP).
REST is true in all its determination as an important guideline for the use of web standards, in contrast to many historically grown method. This part is followed by a return to fundamental web technologies, designed to simplify the development of distributed Web-based systems.
Principle
There are five characteristics which must have a REST service, and it is up to the individual services, as it is implemented.
Addressability
Any service is a RESTful server provides, has a unique address called a Uniform Resource Locator (URL). This " Street and house number in the network " ensures that the offer of a web service in a simple, standardized way of a variety of applications (clients) is available. A consistent addressability also makes it easier to continue to use a web service as part of a mashup.
In addition to the URL that addresses the service itself, REST also uses Uniform Resource Identifier ( URI ) to identify individual resources.
Different representations
The accessible at an address services can have different forms of representation ( representations ). A RESTful server depending on what the application requests, deliver different representations (such as HTML, JSON or XML). Thus, the default Web browser on the same URI address both the service and the description or documentation can retrieve. It is not the internal database entry delivered, but the possibly transmitted in a particular encoding or language version, depending on the request document.
Statelessness
REST relies on a stateless client - server protocol that is being used in the normal case, HTTP or HTTPS. Each residue message contains all information in that is necessary for the server and client, in order to understand the message. Neither the server nor the application should store state information between two messages. Such a strict separation of powers between the client and server results in a RESTful web service as a stateless: may be referred (English stateless ). Each request from a client to the server is closed in the sense in it than that it contains all the information about the application state are required by the server to process the request.
Statelessness in the form described here has a favorable effect on the scalability of a web service. For example, incoming requests as part of the load distribution can be easily distributed on any machine: Since each request is self-contained and application information are thus held exclusively on the client side, no session management is required on the server side. In practice, however, many use HTTP cookie -based applications, and other techniques in order to maintain state information.
Operations
RESTful services must provide some operations that can be applied to all services ( called resources ). HTTP, for example, has a clearly defined set of operations, including GET, POST, PUT and DELETE.
HTTP requires that GET " safe" (english safe) must be, which means that this method is purchasing information only and does not cause other effects. The methods GET, HEAD, PUT and DELETE should be idempotent, which in this context means that the multiple sending the same request is no different effect than a single call, according to the HTTP specification.
Use of hypermedia
Both for application information as well as for state changes hypermedia are used: representations in a REST system are typically in HTML or XML format, containing both information and links to other resources. Therefore, it is often possible to navigate from one resource to another, simply by following links without the need for registration databases or similar infrastructures are required. This combination of resources within a REST architecture is also referred to as connectedness.
Implementation
REST unifies the interface between systems to a manageable and - about the expected behavior - standardized set of actions ( " verbs "). What actions are this is not set in REST, but all actions are generally defined.
Most Internet technologies are used for the implementation of the REST architectural style, as an application layer protocol is mainly HTTP.
The client can issue the following commands
Unlike many architectures REST RPC does not encode method information in the URI, as the URI indicates location and name of the resource, but not the functionality that offers the resource. An attempt is made to map the functionality mainly via the HTTP verbs.
Security
In theory, the paradigm requires that all the information you need an application to restore the page state again, are included in the request. In this case, the URI identifies the resource while in the HTTP header information, such as access type (GET, PUT), return format or authentication may be included.
In its pure form, REST can create Web pages and Web services that do not require authentication, or they reach in other ways ( for example by examining the IP address or HTTP authentication ), which many applications can be covered already. Alternatively, for example, HMAC, OAuth or OpenID be used.
Since REST - in contrast to SOAP with WS-Security - does not define any encryption methods in safety-critical messages encrypted transport protocol such as HTTPS is used.
HATEOAS
Hypermedia as the Engine of Application State, HATEOAS short, is a design principle of REST architectures. In HATEOAS the client of a REST interface navigates exclusively on URLs which are provided by the server.
Depending on the chosen representation is done providing the URIs via hypermedia, eg
- In the form of " href " - and " src" attribute in HTML documents or HTML snippets, or
- In defined and documented for the specific interface JSON or XML attributes or elements.
Abstract considered to provide HATEOAS compliant REST services represents a finite state machine whose state changes made by the navigation using the provided URIs.
By HATEOAS a loose binding is ensured and the interface can be changed. In contrast, a SOAP-based web service communicates via a fixed interface. For a change of service here has a new interface will be provided and are defined in the interface description ( WSDL document).
REST Maturity Model
The REST Maturity Model ( REST maturity model ), RMM short, is a standard developed by Leonard Richardson scale that indicates how much a service based on REST.
- Uses XML -RPC or SOAP
- The service is addressed by a single URI
- Uses a single HTTP method ( POST)
- Uses different URIs and resources
- Uses a single HTTP method ( POST)
- Uses different URIs and resources
- Uses multiple HTTP verbs
- Based on HATEOAS; used hypermedia navigation
- Uses different URIs and resources
- Uses multiple HTTP verbs
Demarcation from other communication mechanisms
When REST is a design pattern, which can be implemented with different mechanisms. One innovation is the use of as many HTTP verbs in connection with the action to be executed. In contrast, SOAP was used mainly with the verbs GET and PUT for example. The difference is more so in the wider use of HTTP as protocol and URI as an identification mechanism for concrete objects. In the past, was carried out in contrast with more of a RPC SOAP -based construction of the interfaces. Due to the strong requirement of the design pattern in REST such services are built structured by definition, and allows the use of clean URLs.