Four levels of REST API Design

Leonard Richardson proposed a classification for services on the Web that we’ll use in this book to quantify discussions on service maturity.* Leonard’s model promotes three levels of service maturity based on a service’s support for URIs, HTTP, and Hypermedia.

Level Zero Services
The most basic level of service maturity is characterized by those services that have a single URI, and which use a single HTTP method (typically POST). For example, most Web Services (WS-)-based services use a single URI to identify an endpoint, and HTTP POST to transfer SOAP-based payloads, effectively ignoring the rest of the HTTP verbs. We call it POX – Plain old XML, because all service method at level 0 is based on XML to describe the resource.

Level One Services
The next level of service maturity employs many URIs but only a single HTTP verb. The key dividing feature between these kinds of rudimentary services and level zero services is that level one services expose numerous logical resources, while level zero services tunnel all interactions through a single (large, complex) resource.

Level Two Services
Level two services host numerous URI-addressable resources. Such services support several of the HTTP verbs on each exposed resource. Included in this level are Create Read Update Delete (CRUD) services, where the state of resources, typically representing business entities, can be manipulated over the network.

Level Three Services
The most web-aware level of service supports the notion of hypermedia as the engine of application state. That is, representations contain URI links to other resources that might be of interest to consumers. The service leads consumers through a trail of resources, causing application state transitions as a result. We call it HATEOAS.

%d bloggers like this: