Richardson Maturity Model（RMM）

迈向REST的辉煌

一个模型（由Leonard Richardson开发）将REST方法的主要元素分解为三个步骤。这些引入资源，http动词和超媒体控件。

最近我一直在阅读Rest In Practice的草稿：一本我的几位同事一直在研究的书。他们的目标是解释如何使用Restful Web服务来处理企业面临的许多集成问题。本书的核心是网络是大规模可扩展的分布式系统的存在证明，这种系统运行良好，我们可以从中获得创意，更轻松地构建集成系统。

为了帮助解释Web风格系统的特定属性，作者使用由Leonard Richardson开发并 在QCon演讲中解释的宁静成熟模型 。该模型是考虑使用这些技术的好方法，所以我认为我会对自己的解释有所暗示。（这里的协议示例只是说明性的，我不认为值得对它们进行编码和测试，所以细节上可能存在问题。）

0级 - XML沼泽

该模型的出发点是使用HTTP作为远程交互的传输系统，但不使用Web的任何机制。基本上，你在这里做的是使用HTTP作为你自己的远程交互机制的隧道机制，通常基于远程过程调用。

假设我想与我的医生进行预约。我的预约软件首先需要知道我的医生在特定日期有哪些空位，因此它会请求医院预约系统获取该信息。在0级情况下，医院将在某个URI处公开服务端点。然后，我向该端点发布一份包含我的请求详细信息的文档。

POST /appointmentService HTTP/1.1
[various other headers]

服务器然后将返回一个文件给我这个信息

HTTP/1.1 200 OK
[various headers]<openSlotList><slot start = "1400" end = "1450"><doctor id = "mjones"/></slot><slot start = "1600" end = "1650"><doctor id = "mjones"/></slot>
</openSlotList>

我在这里使用XML作为示例，但内容实际上可以是任何内容：JSON，YAML，键值对或任何自定义格式。

我的下一步是预约，我可以通过将文档发布到端点再次完成预约。

POST /appointmentService HTTP/1.1
[various other headers]<appointmentRequest><slot doctor = "mjones" start = "1400" end = "1450"/><patient id = "jsmith"/>
</appointmentRequest>

如果一切顺利，我会得到一个回复​​，说我的预约已被预订。

HTTP/1.1 200 OK
[various headers]<appointment><slot doctor = "mjones" start = "1400" end = "1450"/><patient id = "jsmith"/>
</appointment>

如果有问题，说别人在我之前进来，那么我会在回复正文中得到某种错误信息。

HTTP/1.1 200 OK
[various headers]<appointmentRequestFailure><slot doctor = "mjones" start = "1400" end = "1450"/><patient id = "jsmith"/><reason>Slot not available</reason>
</appointmentRequestFailure>

到目前为止，这是一个直接的RPC风格系统。这很简单，因为它只是抛弃普通的旧XML（POX）。如果您使用SOAP或XML-RPC，它基本上是相同的机制，唯一的区别是您将XML消息封装在某种信封中。

1级 - 资源

在RMM中实现Rest的第一步是引入资源。所以现在，我们现在开始与个人资源交谈，而不是将我们的所有请求提交给单一服务端点。

因此，在我们最初的查询中，我们可能会为给定的医生提供资源。

POST /doctors/mjones HTTP/1.1
[various other headers]<openSlotRequest date = "2010-01-04"/>

答复包含相同的基本信息，但是现在每个插槽都是可以单独寻址的资源。

HTTP/1.1 200 OK
[various headers]<openSlotList><slot id = "1234" doctor = "mjones" start = "1400" end = "1450"/><slot id = "5678" doctor = "mjones" start = "1600" end = "1650"/>
</openSlotList>

使用特定的资源预约预约意味着发布到特定的插槽。

POST /slots/1234 HTTP/1.1
[various other headers]<appointmentRequest><patient id = "jsmith"/>
</appointmentRequest>

如果一切顺利，我会收到类似的回复。

HTTP/1.1 200 OK
[various headers]<appointment><slot id = "1234" doctor = "mjones" start = "1400" end = "1450"/><patient id = "jsmith"/>
</appointment>

现在的区别是，如果任何人需要做任何有关约会的事情，比如预约一些测试，他们首先会得到预约资源，它可能有一个URI http://royalhope.nhs.uk/slots/1234/appointment，并发布到该资源。

对于像我这样的对象，这就像对象身份的概念。我们不是在以太网中调用某个函数并传递参数，而是在一个特定对象上调用一个方法，为其他信息提供参数。

2级 - HTTP动词

我在第0级和第1级使用了HTTP POST动词来处理所有的交互操作，但有些人使用GET或者另外使用GET。在这些级别上，它们没有多大区别，它们都被用作隧道机制，允许您通过HTTP隧道进行交互。级别2远离这一点，尽可能使用HTTP动词以及它们如何用于HTTP本身。

对于我们的插槽列表，这意味着我们要使用GET。

GET /doctors/mjones/slots?date=20100104&status=open HTTP/1.1
Host: royalhope.nhs.uk

答复和POST一样

HTTP/1.1 200 OK
[various headers]<openSlotList><slot id = "1234" doctor = "mjones" start = "1400" end = "1450"/><slot id = "5678" doctor = "mjones" start = "1600" end = "1650"/>
</openSlotList>

在第2级，对这样的请求使用GET至关重要。HTTP将GET定义为安全操作，即它不会对任何状态进行任何重大更改。这使我们可以按任意顺序安全地调用GET，并且每次都可以获得相同的结果。这样做的一个重要结果是，它允许任何参与者路由请求以使用缓存，这是使Web性能与其一样好的关键因素。HTTP包含支持缓存的各种措施，可供所有通信参与者使用。通过遵循HTTP的规则，我们可以利用该功能。

预约一个约会，我们需要一个HTTP动词，改变状态，POST或PUT。我将使用与之前相同的POST。

POST /slots/1234 HTTP/1.1
[various other headers]<appointmentRequest><patient id = "jsmith"/>
</appointmentRequest>

在这里使用POST和PUT之间的权衡比我想要进入这里更多，也许我会在某一天做一个单独的文章。但我想指出的是，有些人错误地在POST / PUT和创建/更新之间建立了对应关系。他们之间的选择是相当不同的。

即使我使用与第1级相同的帖子，远程服务如何响应还有另一个显着差异。如果一切顺利，服务会回复201的回应代码，以表明世界上有新的资源。

HTTP/1.1 201 Created
Location: slots/1234/appointment
[various headers]<appointment><slot id = "1234" doctor = "mjones" start = "1400" end = "1450"/><patient id = "jsmith"/>
</appointment>

201响应包含一个带有URI的位置属性，客户端可以使用该URI来获取将来该资源的当前状态。此处的响应还包括该资源的表示，以便立即保存客户端的额外呼叫。

如果出现问题，还有其他差异，例如其他人预订会话。

HTTP/1.1 409 Conflict
[various headers]<openSlotList><slot id = "5678" doctor = "mjones" start = "1600" end = "1650"/>
</openSlotList>

此响应的重要部分是使用HTTP响应代码来指示出现问题。在这种情况下，409似乎是一个很好的选择，表明其他人已经以不兼容的方式更新资源。我们没有使用200的返回码，而是包含一个错误响应，我们明确地使用了这种类型的错误响应。协议设计人员需要决定使用哪些代码，但如果出现错误，应该有非2xx响应。2级介绍了使用HTTP动词和HTTP响应代码。

这里存在不一致性。REST倡导者讨论使用所有HTTP动词。他们还通过说REST试图从网络的实际成功中学习来证明他们的方法是合理的。但是世界范围的网络在实践中并不使用PUT或DELETE。有更明智的理由使用PUT和DELETE，但Web的存在证明不是其中之一。

网络存在的关键要素是安全（如GET）和非安全操作之间的强烈分离，以及使用状态代码来帮助传达您遇到的各种错误。

等级3 - 超媒体控制

最后的关卡介绍了你经常听到的HATEOAS（超文本作为应用程序状态引擎）的简称。它解决了如何从列表中开放空位到知道如何做预约的问题。

我们从我们在第2级发送的相同的初始GET开始

GET /doctors/mjones/slots?date=20100104&status=open HTTP/1.1
Host: royalhope.nhs.uk

但是回应有一个新的元素

HTTP/1.1 200 OK
[various headers]<openSlotList><slot id = "1234" doctor = "mjones" start = "1400" end = "1450"><link rel = "/linkrels/slot/book" uri = "/slots/1234"/></slot><slot id = "5678" doctor = "mjones" start = "1600" end = "1650"><link rel = "/linkrels/slot/book" uri = "/slots/5678"/></slot>
</openSlotList>

每个插槽现在都有一个链接元素，其中包含一个URI以告诉我们如何预约约会。

超媒体控件的重点在于它告诉我们接下来可以做什么，以及我们需要操作的资源的URI。我们不需要知道在哪里发布我们的预约请求，反馈中的超媒体控件告诉我们如何去做。

POST会再次复制第2级的内容

POST /slots/1234 HTTP/1.1
[various other headers]<appointmentRequest><patient id = "jsmith"/>
</appointmentRequest>

并且回复包含许多超媒体控件，用于接下来要做的不同事情。

HTTP/1.1 201 Created
Location: http://royalhope.nhs.uk/slots/1234/appointment
[various headers]<appointment><slot id = "1234" doctor = "mjones" start = "1400" end = "1450"/><patient id = "jsmith"/><link rel = "/linkrels/appointment/cancel"uri = "/slots/1234/appointment"/><link rel = "/linkrels/appointment/addTest"uri = "/slots/1234/appointment/tests"/><link rel = "self"uri = "/slots/1234/appointment"/><link rel = "/linkrels/appointment/changeTime"uri = "/doctors/mjones/slots?date=20100104@status=open"/><link rel = "/linkrels/appointment/updateContactInfo"uri = "/patients/jsmith/contactInfo"/><link rel = "/linkrels/help"uri = "/help/appointment"/>
</appointment>

#