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.
- 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.
- Roy Fielding is also a principal author of HTTP specifications. He used REST to design HTTP 1.1 and URI.
- 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.
- 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.
- 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.
- If a RESTful API is designed with HTTP, its maturity can be measured by the Richardson Maturity Model (RMM).
- RMM classifies the API design by four levels: #0 Swamp of POX, #1 Resources, #2 HTTP Verbs and #3 Hypermedia Controls.
- 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.
- 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”.