Java Reference
In-Depth Information
Level 0: The Swamp of POX (Plain Old XML)
This model uses HTTP as a transport protocol to invoke remote interactions. It does not use the
protocol to indicate an application state; it is usually just used to tunnel requests and responses on
one URI, such as
/getUser
, using only one HTTP method. This is a classic example of an RPC
r
model and is more akin to SOAP and XML‐RPC than REST.
Level 1: Resources
This is where the model starts to be able to distinguish between different resources. It will talk
to different end points because each end point represents a different resource. It uses a URI like
POST resources/123
, but it still uses just one HTTP method.
Level 2: HTTP Verbs
At this level, you implement full use of the HTTP verbs and combine them with your resource nouns
to provide the type of REST that has been discussed so far in this chapter. You take full advantage
of the features that HTTP offers to implement your RESTful API. However, you still have not
reached the level of a truly RESTful API.
Level 3: Hypermedia Controls
At this level, the model uses HATEOAS (Hypermedia As The Engine Of Application State) to direct
the application state. The objective of hypermedia controls is to advise the client of what can be
done next and to supply the URIs necessary to perform the next action. You will see how this works
and how to implement HATEOAS later in this chapter.
DESIGNING A RESTFUL API
A well‐designed RESTful API means a well‐dei ned uniform interface. For this, a thorough
understanding of the HTTP methods and response codes is important, and a complete knowledge
of the data structure of your application is needed. The objective is to combine them into a simple,
clean, and beautiful resource URI.
WAR STORY
One of the companies I worked for had a tradition that once a team completed a
project, it presented its project to the other teams. It was at about the same time
that REST was getting popular. One of the teams decided to build a REST back
end to serve both the mobile and the web clients. We were thrilled and listened
intently to how they successfully built a beautifully designed REST back end and
how it was able to serve data for both systems. As the team's lead started to give
technical details about the system, we realized they were maintaining the client
state on the server side. Not at all RESTful.
continues
