RESTful Web APIs

Chapter 3. Resources and Representations

So far I’ve shown you two examples of REST in action: a website (Chapter 1) and a web API (Chapter 2). I’ve talked in terms of examples, because there’s no RFC for REST the way there is for HTTP or JSON.

REST is not a protocol, a file format, or a development framework. It’s a set of design constraints: statelessness, hypermedia as the engine of application state, and so on. Collectively, we call these the Fielding constraints, because they were first identified in Roy T. Fielding’s 2000 dissertation on software architecture, which gathered them together under the name “REST.”

The runaway popularity of the term “REST” is out of proportion to the importance of REST to Fielding’s dissertation. Fielding used REST primarily as an example, to tie something you’re already familiar with (the Web) into a general design process. REST became popular because the term happens to describe the architecture of one of the most successful technologies in human history.

In this chapter, I’ll finish my explanation of the Fielding constraints in terms of the World Wide Web. My “bible,” as it were, will not be the Fielding dissertation. (You can see Appendix C for a detailed, API-centric discussion of Fielding.) Instead, I’ll be drawing from the W3C’s guide to the Web, The Architecture of the World Wide Web, Volume One (there is no Volume Two). The Fielding dissertation explains the decisions behind the design of the Web, but Architecture explains the three technologies ...