Restful levels：

要知道API的哪个级别，Richardson引入了一个名为Richardson Maturity Model的模型。正如名称本身所暗示的，它讲述了REST API的成熟度级别。

根据Richardson成熟度模型，任何REST API都属于从0级到3级的任何成熟度级别，如下所述。

开发的每个REST API都不必高达3级。但是这个模型可以帮助REST API的开发人员知道他们的API属于哪个级别，以及如何通过在上面的模型层次结构中向上移动来改善他们的API 。

0级：POX的沼泽

在此级别设计的API根本不是Rest API，而是基于SOAP的Web服务发生的地方。
在此级别，没有基于资源的URI，超媒体的概念，也没有正确使用HTTP协议（这是REST API的关键特性）。实际上，属于此级别的API不会充分利用或利用HTTP协议的全部潜力。HTTP仅被视为传输层协议或仅仅是客户端和服务器之间的隧道机制。

第1级：基于资源的地址/ URI

这是REST API的起始级别。在这个层面上，概念的资源基础地址被引入，它告诉你应该有个人的URI服务器上的每个资源（不像LEVEL 0，我们有一个单一的URI从客户端的每个传入的请求）。
这就像减少了从单个端点（处理所有操作的LEVEL 0端点）到多个基于资源的URI（如Divide and Conquer算法）的负担。
示例：创建发送到URI1的推文请求，删除推文请求转到URI2等。因此，无论我们是创建新推文，删除推文，还是更新推文，操作信息（创建，更新，删除推文）仍然是在请求正文中。在上面的twitter API中，我们可以将TWEET，COMMENT和FOLLOWER视为上述应用程序中的不同资源。
如果我们只是设计了基于资源的URI 而没有其他任何东西，那么我们处于成熟度模型的第1级。在这种情况下，HTTP仅用作客户端和服务器之间的隧道，我们没有利用HTTP作为应用程序层协议的潜力。
大多数REST初学者都是在这个LEVEL上设计REST API：

第2级：利用HTTP的潜力作为应用层协议

在此级别下开发的REST充分利用了HTTP作为应用程序层协议的全部潜力。
在此LEVEL开发的REST API使用标准HTTP方法/谓词和不同的HTTP状态代码对资源URI执行不同的操作。因此，请求机构将不再提供此级别的操作信息。因此，这个API比在LEVEL 0和LEVEL 1开发的API要成熟得多。

第3级：使用超媒体或HATEOAS

在第1级中，引入了基于资源的URI概念，在第2节中，我们利用HTTP方法充分利用了HTTP协议。LEVEL 3使用Hypermedia （也称为HATEOAS -Hypermedia作为REST世界中的应用程序状态引擎），它驱动API客户端的交互。通常，API客户端不知道所有资源端点，并且REST不会处理API文档（它可以告诉API客户端有关所有端点的信息），这与我们拥有WSDL的SOAP不同，后者向API客户端提供有关服务的信息。
使用概念HATEOAS使不同的基于资源的端点知道API客户端，即发送一些超媒体作为端点响应的响应，其反过来充当应用程序状态的引擎，因此名称为HATEOAS。REST API中的HATEOAS概念使API自我记录，因此不需要API文档。
在这个LEVEL 3开发的API通常被认为是完全RESTful API，这是我们看到REST API的魅力所在。

HATEOAS：

超媒体作为应用程序状态引擎（HATEOAS）是REST应用程序体系结构的一个组件，它将其与其他网络应用程序体系结构区分开来。

使用HATEOAS，客户端与网络应用程序交互，其应用程序服务器通过超媒体动态提供信息。除了对超媒体的一般理解之外，REST客户端几乎不需要知道如何与应用程序或服务器交互。

相比之下，CORBA中的客户端和服务器通过文档或接口描述语言（IDL）共享的固定接口进行交互。

HATEOAS约束将客户端和服务器分离的方式使服务器功能能够独立发展。

示例：

REST客户端通过简单的固定URL进入REST应用程序。客户端可能采取的所有未来操作都在服务器返回的资源表示中发现。用于这些表示的媒体类型以及它们可能包含的链接关系是标准化的。客户端通过从表示中的链接中进行选择或通过以其媒体类型提供的其他方式操纵表示来转换应用程序状态。通过这种方式，RESTful交互由超媒体驱动，而不是带外信息。^[1]

例如，^[2]此GET请求获取帐户资源，以XML表示形式请求详细信息：