What Is REST? | 187Fielding’s thesis is very general; it actually applies to any “network-based architec-
ture.” However, REST is most commonly applied to the World Wide Web and
HTTP, and we will constrain our subject of discussion in this chapter to REST’s
application to HTTP. Necessarily, this will impose constraints and guidelines not
derived from Fielding’s thesis. Therefore, the principles explained in this chapter are
a subset of those of Fielding’s REST.
In some ways, REST is simply “HTT Pas it was meant to be.” As the Web grew in
popularity, many of the original design decisions that guided HTT Pwere ignored.
Developers of web applications tended to see things like HTT Pverbs and response
status codes as incidental to the application, or as a triviality to be dealt with when
time allowed. Using HTT Pas intended was often seen as unnecessary or arduous.
However, in recent years, a return to REST principles indicates that HTT Pwas good
enough after all. Developers are learning these lessons:
- Most, if not all, domains can be fairly easily modeled as sets of CRUD (create, read,
update, delete) operations. These operations roughly correspond to HTTPPOST,
GET,PUT, andDELETE, respectively. In this way, the set of actions is standardized. - Names corresponding to resources (/person/123) are generally consistent, robust,
and understandable. Names corresponding to service endpoints (/personService)
tend to be too broad and underspecified, while names corresponding to RPC calls
(/person/show/123, when accessed withGET) are redundant. - Orthogonality wins. Names should identify resources; nothing more or less. Suc-
cess and failure should be inferred from the HTT Presponse status, not from an
error message within the payload. A resource can have multiple representations,
but they should all be identified as originating from the same resource (and their
names should reflect that).
The combination of nouns, verbs, and content types is often referred to as theREST
triangle. Together, the three corners of the triangle define the architecture. A REST-
centric design decomposition is often done by deciding on the nouns (identifying and
naming things), selecting a uniform set of verbs (easy if you are using HTTP), and
choosing content types.
Verbs
Verbs correspond to actions on resources. A verb will either send a representation of
a resource from the server to the client or update the resource on the server with
information from the client.
In REST, verbs are a constrained territory. While the set of content types is open for
revision and expansion, and resource names are infinitely expandable, the set of
verbs is fixed. However, the constraints put on the scope of verbs allows them to be
universal; any verb can be applied to any noun.