如何度量应用的 RESTful 成熟度？

过去几年间，你很难去忽视使用 RESTFul 方法构建企业级应用变得越来越普及的事实。现在，人们似乎不再争论 REST 还是 WS-* 呢？，也不再谈论 REST 和 SOA 是否互补，而是转向讨论基于REST 实现的成熟度了。不幸的是，即便是这一话题，也可能引起人们的迷惑、不同意见和争论。当谈及REST 成熟度时，一些人常常会引用 Richardson 成熟度模型（Maturity Model），并视之为正确的度量方法。譬如，Martin Fowler 在其最新的博文里就谈到了这一模型的几个级别。

• 第一级：在架构中引入资源（Resource）的概念。
• 第二级：支持 HTTP 动词。
• 第三级： HATEOAS 。

Martin 这么说：

我还要强调，虽然 [ Richardson 成熟度模型] 是思考 REST 各种元素时很好的方法，但它却不能作为区别 REST 级别的定义。Roy Fielding 已经清晰地做了定义—— [Richardson 成熟度模型] 的第三级才是 REST 的先决条件。

Martin 继续引用他与 Ian Robinson 的一次谈话，这此谈话使得双方在某些层面上达成一致：

[Ian] 说他发现了这一模型里一些有意思的地方 [……] 即它与通用的设计技术的关系。 - 第一级通过分治法（divide and conquer）解决复杂性问题，它将较大的服务端点分解成多个资源（Resource）。

• 第二级引入一组标准的动词，这样我们就可以用相似的方法来处理类似的问题，这消除了不必要的不确定性。
• 第三级引入可查找性，提供了使这一协议体现自描述性的手段。

其结果就是这样一个模型，它有助于我们思考我们要提供的 HTTP 服务，也有助于我们约束他们的使用者的期望。

虽然该模型看上去有一些支持者，但是 REST 社区中持反对意见者也不在少数。比如，在这篇同样引用了 Roy 关于怎样才称为 RESTful 系统的论文的文章中，作者说：

因此，根据 Roy 的严格规定，超媒体（hypermedia）是 REST 的先决条件。任何其他东西不应该自我标榜为 REST。如此，该成熟度模型看起来应该是这样的： - 第一级：非 REST

• 第二级：非 REST
• 第三级：REST

不过，有一评论指出：

事实上，如果你漏掉“任何”该 [成熟度模型] 的级别，最后都不是 REST（不过我喜欢将“HTTP 动词”替换成“一组预定义的，广泛认可的动词”）。可是从实现的角度看，你不能跳过第一级就达到第三级，所以，我认为这个次序是能说的过去的。

如今，《RESTful Web Services Cookbook》一书的作者 Subbu Allamaraju 也加入了这一论战，他最近写了一篇有关使用 Richardson 成熟度模型的博文。事实上，他开篇就说不能使用该模型作为判断应用的 RESTful 成熟度的尺度。他说：

根据应用所支持的 REST 限制，而非它有没有选择正确的限制来满足其应该的质量属性，这种判断是毫无意义的。就好比一个应用选择 RDBMS 而非 NoSQL 存储，在没有弄清作出这一选择所基于的原因之前就贸然地批评它一样。认为应用一旦使用了超文本限制，它获得了“REST 的优点”，同样很傻。真正重要的是它是否实现了该应用应该达到的质量属性。

这篇博文引起了一组有趣的来来回回的评论。比如， Mike Amundsen 说：

虽然我同意你的观点——“一旦应用的实现遵循了 Fielding 的 REST 限制就自动变成了某项工作的正确做法”——这一判断是错误的，然而，我不同意你的“评判一个实现是否符合一些限制（就 REST，C2 等来说）”是“毫无意义的”或者是“傻事”[……] 你想表达的思想是？换言之，为什么不需要评判合规性？你认为重要的东西，那一样不能从评判中得到呢？从评判中得到的东西那一样又是不重要的呢？从评判中得到的东西会产生误解么？评判中隐藏了一些可能导致危险、误导或无用的前提假设么？

此后，Mike 就判断应用的 RESful 程度与实现 REST 风格的应用的好处二者之间的差别单独写了一篇博文。

Subbu 这样回应的 Mike 最初的评论：

评判需要有一个上下文语境，而质量属性提供了这一语境。只围绕 REST 限制作评判可能会导致差劲的 / 有问题的决策。[……] 不存在放之四海皆准的好坏标准。

Mike 回应：

我理解你的观点了。你所谈的是实现的早期行为：“今天，我要构建一个 Web 应用；这些是我要用的限制（因为 Fielding 这么说……）”，在以上例子中，以满足一组“限制”为核心是不正确的。因为你可以说，早期的工作应该集中在应用应该支持的“质量”上。我猜你还仍然会赞同：在确定了质量属性之后，在实现中选择正确的限制来支持这些属性是有意义的（就像 Fielding 的做法）。

Ian Robinson 后来也加入了论战，他赞同盲目使用 Richardson 的模型是不明智的：

[……]Leonard 最初创建这一启发式模型的目的是帮助开发者理解 REST——仅此而已。他通过将通用的、类似的软件开发实践（例如，分治；用同样古老的方法解决同样古老的事情）和 Web 应用（任何东西都有一个地址；使用 HTTP 来写协调表象传输）做类比而得出这一模型的。

而于此同时， Restfulie 的作者| Guilherme Silveira 在别处尝试坚持并扩展 Richardson 模型，创立了一套 5 步法通往 REST 架构的成熟度模型，不同于 Richardson 的是，这一模型不限定基于 HTTP。

• 第一步：明确并使用统一的接口。
• 第二步：将数据链接起来，让用户可以通过资源的状态和关系进行导航。
• 第三步：给链接添加语义“内容”。
• 第四步：创建客户端“仅根据资源表象关系和对媒体类型的理解做决策”。
• 第五步：“通过应变能力强的代码去指导用户如何应对特定的从未遇见过的媒体类型，比如新出现的媒体类型定义。”

这一个 5 步方法更好么？它解决了 Subbu 等人所谈论的有关最初的模型不应该盲目使用的担心么？或者有没有更好的解决方法呢？

查看英文原文： How do you measure the RESTful-ness of an application?