Java Reference
In-Depth Information
not have a World Wide Web Consortium (W3C) standard. It is a set of conventions, styles, and
approaches that have been agreed upon over time by use and convention.
The term
REST
was coined by Roy Fielding in his 2000 doctoral dissertation titled “Architectural
T
Styles and the Design of Network‐Based Software Architectures.”
1
Since then, the REST concept
has been widely adopted by developers and architects such that it has become an integral part of
many languages and frameworks. For example, Ruby provides a natural way to use RESTful routes,
and the Spring framework provides a simplii ed way to implement Hypermedia As The Engine Of
Application State (HATEOAS), which is level 3 of the Richardson Maturity Model of REST support
(more on this later).
2
REST is usually referred to as an architectural approach rather than a design pattern. However,
REST was developed against common problems faced in enterprise app, which is the same idea
behind the design patterns.
WHAT IS REST?
REST means many things to many people, and discussions can become quite theoretical. This
chapter discusses it from the perspective of a developer who wants to implement a RESTful
application programming interface (API) for a forum site discussing movies.
IN THE WORDS OF ROY FIELDING
REST emphasizes scalability of component interactions, generality of interfaces,
independent deployment of components, and intermediary components to reduce
interaction latency, enforce security, and encapsulate legacy systems.
The most practical way of thinking about REST is as a style for formatting URIs that represents
resources (data) your application can provide and resources that it can store. What is meant by
resources? In a forum website, you have many resources, such as the site's users and the users' posts.
These resources are represented by nouns and combined with an HTTP method to form a RESTful
uniform resource identii er (URI). For example, you can represent an account resource with the URI
/accounts
and combine it with the HTTP
GET
method such that a request to this URI would return
all accounts. Likewise, you can represent an identii able account resource by appending the post's
ID to the URI like so:
/accounts/:id
. A
GET
request to this URI returns the details of the account
with the given ID. Not only can you get resource representations by using a RESTful URI, you can
create resources. To do this, you would create a URI using the HTTP
POST
method. For example, to
create a new account resource, you would send a
POST
request to the URI
/accounts
with a payload
in the HTTP body containing the data necessary to create the resource.
As you have gathered, a URI represents a resource on a remote server, and the method of requesting
the resources (the HTTP method) implies certain actions on that resource.
It is tempting to map HTTP methods to create, retrieve, update, and delete (CRUD) actions (for
example,
POST
to Create and
GET
to Read).
3
However, this is not in the spirit of REST and does not
