Java Reference
In-Depth Information
help in the understanding of resource representations. In fact, it's more akin to a remote procedure
call (RPC) pattern implementation, which is at level 0 on the Richardson Maturity Model. You
are only interested in implementing REST at the highest level: level 3, please refer to the section,
“Richardson Maturity Model of REST API” for full details.
A RESTful API is not about actions; it's about nouns. These nouns represent resources. So you'll
learn about a post resource, a user resource, and an address resource as opposed to verbs such
as
getUser
,
r addPost
, and
deleteAddress
. REST is different from simple object access protocol
(SOAP) and RPC, which are about the actions you want to perform on the application's data. In a
RESTful sense, you would call a URI with an appropriate HTTP method.
Each resource is identii ed by a URI. There may be multiple ways to refer to the same resources,
so you might be able to access the same resource from different starting points. For example, you
can obtain the resource that represents a user by accessing the user directly via the URI
GET /
users/:id
or by going from one user to the list of users who follow that user and then to the user
GET /user/:id1/followers/:id1
. The representation of the resource is not the actual resource
itself; it's a representation of the resource, and it is perfectly valid for the same resource to be
represented in different ways.
The resource representation l ow is bidirectional between client and server and represents at least
part of the resource state. When that happens, it contains just enough data to create, modify, or
delete that resource on the server.
Resource representations are typically JavaScript Object Notation (JSON) or Extensible Markup
Language (XML), but they can be any format, including a custom representation.
THE SIX CONSTRAINTS OF REST
According to Roy Fielding's dissertation, a truly RESTful architecture conforms to all but one of the
stated constraints. This group of constraints is called the REST style.
Client‐Server
The client‐server constraint is based on the separations of concerns principle and dei nes clearly the
separation between the client and the server. The constraint is simple and requires a client to send a
request and a server to receive that request. The server may respond to the client's request.
Uniform Interface
This constraint dei nes the interface between the client and the server, stating that it should be
as generic and simple as possible. You have already learned that a resource is a representation
of the data, and the client does not have direct access to the data. This constraint dei nes how
that resource is represented by nouns and that the interface is maintained by the creator of the
actual data system. This is to ensure some degree of constancy of the interfaces over time. The
constraint does not specify that the implementation should use the HTTP protocol, but it is almost
always based on HTTP. As you have already seen, if you use the HTTP specii cation, the URI is
constructed from the resource nouns and the HTTP verbs.
