# On the Need for a General REST-Security Framework
## 2 REST Foundations  
Besides the dissertation of [PERSON] [1], there neither exists a definition nor an unified understanding of the term REST and its underlying principles and concepts. Often enough it is mistaken as being a standard composed of its underlying foundations HTTP and uniform resource identifier (URI) [12]. The source for this diffuse view on REST lies mainly in the fact that the two aforementioned standards have been the only notable technology choice for implementing REST-based service systems ever since. For the purpose of this paper it is henceforth demanding that the term REST is defined unambiguously. The aim of REST is to provide a guideline for designing distributed systems that possess certain traits including performance, scalability, and simplicity. These architectural properties are realized by applying specific constraints to components, interfaces, and data elements. These constraints are subsequently introduced with the guidance of Figure 1.  
REST is constrained to the client-server model in conjunction with the request-response communication flow. A REST client performs some kind of action on a targeted resource by issuing a request. For this, the request must contain a resource identifier and the action to apply to the addressed resource. Depending on the action, the request and response messages may contain additional meta-data elements, which are categorized in resource data, resource meta-data, representation data, representation meta-data, and control data. The set of available actions in conjunction with a unique scheme for identifying resources as well as the additional meta-data is known as the uniform interface since it is consistent for all managed and provided resources. Since REST-based systems are constrained to be stateless, messages need to contain all required data elements in order to relieve the server from maintaining state for each client. As REST messages  
Figure 1: Overview of the representational state transfer (REST) constraints and principles (on the basis of [13]). embody all required data elements, which are predefined and standardized by the uniform interface, their semantics are visible and are hence self-descriptive for all intermediaries and endpoints so that all components in a REST architecture can understand the intention of a message without knowing each other in advance. In a request to read access a resource, for instance, the request contains the resource identifier along with representation meta-data to signal in what data format the resource should be delivered from the server to the client. Moreover, a request can include further meta-data required by intermediaries including state and caching information. The according response provides information on its meaning and in case it denotes that the addressed resource is available, it is contained in the message body in the requested representation. Once a response is received, it transfers the receiving client into a new state. In another setting, in which the request triggers the creation of a new resource, the request contains the resource in the request message body in some representation. The response then gives feedback on the resource state and whether it has successfully created or not. Again, further meta-data elements can be included in addition, providing information on the authentication, the session and the freshness of a resource in respect to caching. Moreover, the meta-data elements as well as the resource representation of the response may contain further resource identifiers--i.e., hyperlinks. Based on these resource identifiers and their description, a client is able explore other resources and transfer its state by starting a new request with a distinct resource identifier and meta information. This REST property is known as hypermedia as the engine of application state (HATEOAS). The principles and constraints representing REST are fairly abstract making it adoptable in any environment that contains technologies suitable for implementing the REST constraints.