如何度量应用的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?