REST API 还有新麻烦？

最近 George Reese 正在把他和 Adrian Cole 共有的一些在云端使用各种 SOAP 和 REST API 的经验写出来，对此我们早先也做了报道。现在 George 的原作在 twitter 和各类博客中激起了大量的辩论。例如，William Vambenepe 同意他大部分的言论，但有一小部分持不同意见，比如说对 JSON 和 XML 的支持：

我不赞成：有两个版本的协议就说明有一个是多余的（这个链接后的帖子并不是特别在讨论 JSON/XML 的对立性，但它的逻辑可以适用，就像 Tim Bray在评论中所指出的一样）。

而 William 也不同意 George 声称 REST 比 SOAP 要好：

未必对所有集成项目来说都是正确的，但在云 API 的背景下，我同意这一点。只要它是“实用的 REST”，而没有为了取悦 REST 警察而做些很傻的扭曲。

有意思的是，有一个看法引起了 William 的注意．．．

提供优秀的 API 文档减少了我对你帮助的需求：这是不言而喻的（要是想找找笑点，看看 George 博客文章里这位评论者，他写道“如果你给一个 API 写文档，你的 API 马上就跟 REST 没关系了”，我情愿相信这只是玩笑，不过看起来好像写得很认真）。

…这是来自于 Jan Algermissen ，他很严肃地回答了 William 的评论：

关于“提供优秀的 API 文档减少了我对你帮助的需求”。如果你给一个 API 写文档，你的 API 马上就跟 REST 没关系了。在 RESTful 系统中真正的约定是媒体类型，而不是 API 文档。我建议你把那部分放到“缺点”！请看： http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

然而， Stu Charlton 引起了可能是最热烈的讨论，并在他的关于 API 的麻烦的文章中总结成了 5 点。

1. REST API 是一个好心办坏事的例子。REST 的目的就是消除特定的 API，而不是滋生它们。
2. 如果谁告诉你不应该为 REST API 写文档，他们实际是在说你不该写 API，而不是说你不该写文档。
3. 话说回来，说你不该写 API 的 REST 的拥趸也有点傻，因为他们也没有提出什么好的选择。定制的媒体类型算不上一个。
4. 这样说来，以我的观点，在我们有一两个可利用的普遍媒体类型之前，对 80% 的 REST API 来说，我们只是自寻烦恼。
5. 我已经差不多放弃拥护 REST 了，因为现在来看不太可能。人们只是想发布一些只能用 6 个月的 API，而不是构建可以进化 10 年以上的系统。

特别地，关于 Jan 早前的评论，Stu 在下面表示了支持：

Jan Algermissen 的关于如果你做 API 文档你就不是在做 REST 的看法实际上基本说到了点子上，但却被人冷嘲热讽。我完全理解，如果你只想在眼下发布一个 API，如果短期行为是有意为之，或者以架构式风格玩弄新潮名词，这个评论听起来有多傻。但是如果我们真的想要利用这个风格的优点，我们就会着手解决核心的问题，为这些用例设计一两个通用媒体类型。

就像在 REST 社区中最常见那样，Stu 的文章也引来了来自正反双方许多有趣的评论。进而，可以说这个争论是与我们前面一篇文章密切相关，这篇文章是关于 REST 是否可以被认为是在企业内成功的，而且同样也可能与 Jean-Jacques 相信我们现在正处在一个后 REST/SOAP 世界的原因密切相关。

REST 所制造的问题（……）在于，现在随便一个 API 设计者都自认为称得上是分布式计算的大师，像个艺术家般决定把版本和凭证之类的东西放在什么样的地方，凭自己喜好把操作和查询编码到一堆报文头、符号、查询参数、报文体等等之中。要是你问我的话，我得说 REST 制造了软件工业中前所未有的暴政。

Stu 最后以他认为应用 REST 导致的一些规则变化作为总结：

1. 你不能假设你的服务的最终用户是一个程序员（或浏览器）。Stu 的看法是，如果你的目标是让程序员学习你的 API，那就没有必要使用 REST。
2. 你不能假设只有一个站点会实现你的接口。“WEB 的整体精神是分享信息——发布一个 API 造成作为发布者的你在全权控制的假设。其实是消费者——客户端代理本身控制着什么样的信息如何被消费和操作。”
3. “需要文档化的接口语义是你用来描述你的数据和链接的媒体类型。你的 URL 的结构绝不应该成为这个语义的一部分。”
4. “但是在定制的媒体类型里这么做说明你是唯一一个实现你自己的接口的人。当然每个媒体类型总要有个开始，但是这确实没什么帮助，除非你理解其他人可能会实现你的接口而不只是与之会话。

他提出的最后一点规则的改变值得单独提出来因为它多年来都是很多争论的主题:

我们所能希望的最好的情形是有人或组织能承担这个责任提出一两个通用媒体类型以及指南，来帮助描述和文档化一个数据 WEB 的接口给程序员使用。如果你愿意可以称之为描述语言。一些 REST 的拥趸不喜欢描述语言这个想法，而我认为这实际是 80/20 的比例，如果开发者真的打算用它原本的用法去使用这个架构。

那么你是怎么想的？我们是光缺少良好定义的设计好的 REST API 的规则，还是像 JJ 暗示的那样这是一个失败的运动？

查看英文原文： Yet More Trouble with REST APIs?