A Bite of { REST }

I have seen people confused by terminologies like REST, RESTful API and HTTP in different tech discussions. Therefore I hope this short article can help demystify these confusing concepts.

  1. REST is an architectural style for network-based hypermedia systems with a set of interaction constraints. It is originated by Roy Fielding in his doctoral dissertation Architectural Styles and the Design of Network-based Software Architectures from UCI.
  2. Roy Fielding is also a principal author of HTTP specifications. He used REST to design HTTP 1.1 and URI.
  3. REST is characterized by its six guiding constraints: #1 Client-Server, #2 Cacheablility, #3 Stateless, #4 Layered System, #5 Code on Demand (optional) and #6 Uniform Interface.
  4. Usually, when we are talking about RESTful API design, we are talking about the design of #6 Uniform Interface upon a system which has satisfied at least the first 4 constraints.
  5. Using HTTP is the most common approach to design a RESTful API, with HTTP verbs like GET, POST, PUT and DELETE, as well as HTTP response codes. But a RESTful API is not necessarily to be designed with HTTP.
  6. If a RESTful API is designed with HTTP, its maturity can be measured by the Richardson Maturity Model (RMM).
  7. RMM classifies the API design by four levels: #0 Swamp of POX, #1 Resources, #2 HTTP Verbs and #3 Hypermedia Controls.
  8. Most of the industrial RESTful API design has reached the level #2, but Roy Fielding considers the level #3 RMM as a pre-condition of REST.
  9. When we reach level #3, we finally achieve HATEOAS(Hypermedia As The Engine Of Application State), which means a “REST client needs no prior knowledge about how to interact with an application or server beyond a generic understanding of hypermedia”.


One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.