Java Reference
In-Depth Information
REST services are stateless
REST services should not require state stored on the server. Fielding states it best himself:
“each request from client to server must contain all of the information necessary to understand
the request, and cannot take advantage of any stored context on the server” (pages 78-79).
Having all of the state reside in the client improves stability and scalability. Cache-ability is
important too, especially for GETs.
Server sessions should notbe used, and everything that you need to process a request should
be contained in that request. There are certain constraints that make cookies a popular way to
store state on the client. Some sites that advertise a RESTful architecture use cookies to store
recently viewed items, currency preference, and shopping cart identifiers, for example. That's
OK, but it's not strictly RESTful.
NOTE
The reason cookies violate REST is stated in Fielding's dissertation, section 6.3.4.2. To summarize
his comments, cookies typically store information that encompasses a user's interaction with an entire
site and not just the current request, which violates encapsulation. Furthermore, cookies pass data
without defining the semantics that define that data, thereby raising concerns regarding both security
and privacy.
REST services have a uniform interface
There is no WSDL in REST. This constraint on the architectural style of REST is generally
understood as the interface provided by the standard HTTP methods (PUT, GET, POST,
DELETE, etc.), but Fielding doesn't say that. He actually stresses protocol independence, des-
pite the popular reliance on HTTP.
Resources are manipulated through representations
The components in the system exchange data (usually XML documents) that represents the re-
source. For example, if you wanted to update customer information, you would post the XML
document representing that resource to its URI. A representation is simply a sequence of bytes
and metadata in the form of name/value pairs that describe the resource.
Resources have multiple representations. The resource is not the HTML page that might be
returned to a browser when you request it—that is simply one out of many possible represent-
ations of the resource. You could return a variety of formats representing a given resource, as
stated in section 5.2.1 of Fielding's dissertation:
▪ XML
