Six guiding contraints define a RESTful system. These constraints restrict the ways that the server can process and respond to clients requests so that, by operating within these constraints, the system gains
desirable non-functional properties, such as performance, scalability, modifiability, visibility,
portability and reliability. If a system violates any of the required constraints, it cannot be
This is about separation of concerns. Separating the user interface concerns from the data storage concerns improves the portability of the user interfaces across multiple platforms. It also improves
scalability by simplifying the server components. Perhaps the most significant to the Web, however is
that the separation allows the components to evolve independently, thus supporting the Internet-scale
requirement of multple organizational domains.
The client server communication is constrainted by no client context being stored on the server between requests. Each request from any client contains all the information necessary to service the
request, and the session state is held in the client. The session state can be transferred by the
server to another service such as a database to maintain a persistent state for a period and allow
authentication. The client begins sending requests when it is ready to make the transition to a new
state. While one or more requests are oustnding, the client is considered to be in transition.
The representation of each application state contains links that can be used the next time the client
chooses to initiate a new state-transition.
As on the World Wide Web, clients and intermediaries can cache responses. Responses must therefore, implicitly or explicitly, define themselves as cachable or not to prevent clients from getting stale
or inappropriate data in response to further requests. Well-managed caching partially or completely
eliminates some client-server interactions, further improving scalability and performance.
A client cannot ordinarly tell whether it is connected directly to the end server, or to an intermediary along the way. This means that the client doesn't know if it's talking with an intermediate or the
actual server. So if a proxy or load balancer is placed between the client and the server, it wouldn't
affect their communications and there wouldn't be necessities to update the client or server code.
Intermediary servers can improve system scalability by enabling load balancing and by providing shared
caches. Also, security can be added as a layer on top of the web services, and then clearly separate
business logic from security logic. By adding security as a separate layer enforces security policies.
Finally, it also means that a server can call multiple other servers to generate a response to the
Code on demand (optional)
The uniform interface constraint is fundamental to the design of any RESTful system. It simplifies and decouples the architecture, which enables each part to evolve independently. The four constraints
for this uniform interface are:
Resource and identification in requests
Individual resources are identified in requests, for example using URIs in RESTful Web services. The resources themselves are conceptually separate from the representations that are returned to the
client. For example, the server could send data from its database as HTML, XML or as JSON - none
of which are the server's internal representation.
Resource manipulation through representations
When a client holds a represenatation of a resource, including any metadata attached, it has enough information to modify or delete the resource.
Each mesage includes enough information to describe how to process the message. For example, which parser to invoke can be specified by a media type.
Hypermedia as the engine of application state (HATEOAS)
Having accessed an initial URI for the REST application - analogous to a human web user accessing the home page of a website - a REST client should then be able to use server-provided links
dynamically to discover all the available actions and resources it needs. As the access
proceeds, the server responds with text that includes hyperlinks to other actions that are
currently available. There is no need for the client to be hard-coded with information regarding
the structure or dynamics of the application.
Many developers also describe their APIs as being RESTful, even though these APIs actually don't fulfill all of the architectural constraints described above (especially the uniform interface constraint).
One problem with REST is the Maximum characters in an HTTP request header value. The default is 4096. This can become a blocker causing some devs to just use POST in all cases :O.
This is because its maximum body size is usually in the range of 1MB to 2GB.