争论：REST 需要描述语言吗？

追踪上周在此讨论的关于REST vs. WS-* 的争论，值得注意的是，以REST 化服务契约为主题的争论在最近几天日嚣尘上。浮现出的问题是REST 是否需要契约（即按照WSDL 的方式），更更根本的问题是有了契约的REST 还依旧是REST 吗。 Aristotle Pagaltzis 的问题：“REST 需要服务描述语言吗？” 揭开了争论的序幕：

“日前，有人在 rest-discuss 发问是否有描述 REST 服务的标准方法。该问题一再露面（作为回应，通常会画一个指向 WADL 努力的箭头），似乎意味着关于 REST 的一个流行的误解。我认为使用类 WSDL 语言描述 REST 化服务根本就是自相矛盾的说法……”

对此， Paul Mueller 回应道：

“此处，我们讨论的是契约。契约必须以某种方式正规化。英语并非最好的使用语言，尤其是因为我们有如此多的更精确语言可供选择。

我的这个想法这实际上是对我关于数据序列化想法的扩展，服务只是需要被元描述的下一级事物。”

Mark Baker 紧跟而上，他同意 Aristotle 的观点：REST 拥有（以及需要）的唯一契约就是以 4 个动词为基础的 HTTP 协议，这 4 个动词是——POST、GET、DELETE、PUT（事实上 HTTP 1.1 还定义了另一个动词 - HEAD，但是它使用并不广泛）。 Mike Herrick 认为契约确实能增加价值：

“我认为，REST 客户端开发者至少期望能有模式，用来定义在请求 / 响应有效负荷中想出现的东西。恕我直言，WADL 做了非常不错的工作，而且没有画蛇添足。如我所说，与 WSDL 相比较，它是个不错的东西。当 HTTP 是唯一选择的时候，事情是如此的简单（即，相比于愚蠢的协议不可知论调）。如果你不打算使用 WADL，那你就不得不将服务以枯燥无聊的方式文档化。至少，WADL 看起来是一种真正简化文档事物的方法。”

Bobby Woolf（因企业集成模式而闻名）同样认为 REST 需要声明性接口并怀疑当 REST 最终获得这些能力时，结果是否还会与 WSDL 有什么显著不同。John Heintz建议在其间做些手脚，使用他称之为路标的东西，而非描述语言。他的想法是：路标在运行时可以被解析，这将使它们适于改变。问题的症结似乎是：服务消费者对于接口的信心，它由它们所消费的服务定义。这个视角始于 Stefan Tilkov 的评论，他认为存根（stub）和骨架类（skelton）有问题。 Don Box 回复说你必需对你得到的消息结构有信心。对此，Stefan 的回应：

“我同意这一点——我的代码就依赖文档中一些元素和属性。但问题是，即使我的应用只访问它所需要的 XML 中 20% 的元素和属性，列集（散列）/ 序列化（反序列化）（(un)marshaling/(de)serialization）代码同样要求在 XML 和模式之间进行完美地匹配。目前代码产生时就是如此。换句话说：尽管我的应用代码能容忍至少一些变动，但是产生的底层代码则不行。”

Mike Glendinning 的评论强调了 Stefan 的观点，他认为当用户只使用返回消息的 20% 时，为其本身定义新契约更有效。或者如 Joe Gregorio 写下的（在一个相当长的 Q&A 风格帖子中，它通篇都是关于我们是否需要 WADL）：

“Q：人们打算想要描述接口，那有什么坏处？ A：是的，人们想要描述接口，并且那些描述是脆弱的。如果今天我下载一个 WADL 并编译我的客户端，那么明天就会因你改变服务而崩溃。相反，如果你使用超文本（在链接后跟超文本和客户端状态，或基于超文本和客户端状态构造请求），那么当你改变服务器或 URI 结构时，接口将不会被破坏。”

最后，考虑到上文 Stefan 博客中的 2 条评论，问题可能比“REST 是否需要正式的契约”更根本，即“我们需要接口吗？”。首先看看 Steve Jones 的评论：

“契约是个好东西，这已经是被证明的了，我仍然奇怪为什么 REST 人们不喜欢它们。它几乎是理论和实践的东西，在理论上并没有规定，在实践上却是如此。”

与 Eric Johnson 所说相比较：

“……就我看来，被 REST 所吸引（不论以什么形式）的人们，是反抗基于接口的编程而甚于 WS-* 本身——至少我的理由是如此……”

查看英文原文： Debate: Does REST Need a Description Language ?。 - - - - - -

译者简介：胡键，自 2000 年西安交通大学硕士毕业后一直从事软件开发。2002 年开始使用 Java，在项目开发中经常采用 OpenSource 工具，如 Ant、Maven、Hibernate、Struts 等，目前正在研究信息集成方面的规范和技术。可以通过 jianhgreat@hotmail.com 与他联系，或访问博客： http://foxgem.javaeye.com/ 。参与 InfoQ 中文站内容建设，请邮件至 china-editorial@infoq.com 。