看新闻很累？看技术新闻更累？试试下载 InfoQ 手机客户端，每天上下班路上听新闻，有趣还有料！
大约在十年前，围绕基于REST 和 SOAP的系统曾开展了一系列的讨论。有人撰文分析了两类技术的各自利弊所在，而另有人思考了其中哪类技术更为适用，或是都适用。随着 Web 服务趋向于从基于 SOAP 转移到 REST 和 HTTP，关注此问题的争论和讨论大都偃旗息鼓了。目前，大多数 SOAP 从业者已采用 REST（或普通的 HTTP）作为分布式系统的基础。然而，近期Pakal De Bonchamp在 Medium 上撰文“REST 是新的 SOAP”，将使用 REST 比喻为一种“精神类疾病测试”。
这篇文章的篇幅很长，内容详尽。复杂性是文中关注的一个关键问题。在作者 Pakal 看来，对于提供一个简单的 API，使用 RPC 机制可在“数小时”内完成，但如果使用 REST，则可能需要更长的时间。为什么会这样？作者给出了一种解释：
（REST）并没有给出更多的标准，也没有给出更准确的规范，仅是给出了一种模棱两可的“RESTful 哲学”，趋向于陷入无休止的形而上辩论之中，并采用了大量丑陋的解决方法。
REST 方法并不能直接映射为 CRUD 操作。我们该如何确定是否不应重用已有的资源而是需要创建新的资源实例，并且何时可以开始创建？在 Pakal 看来，HTTP 错误代码提供的信息十分有限，而且无法表达更丰富的错误情况。他继续列出了更多的问题，最终给出结论：
你需要在重新造车轮上花费数个小时，甚至没有量身定做的适用车轮。你只能使用一个残缺脆弱的车轮，而且理解这样的车轮还需要阅读需要大量的文件，很有可能在不知深浅的情况下违反了它的使用规范。
Pakal 在文中深入讨论了部分 HTTP 动词的细节，其中包括PUT，以及很少为人关注的PATCH的DELETE：
你想使用
PUT实现资源的更新？那好，但是在部分高高在上的规范中规定了，数据输入必须与由GET接收的数据表示保持一致。那么你应该如何处理由GET返回的大量只读参数（例如创建时间、最后更新时间、服务器生成的令牌等等）？如果你简单忽略了这些参数，这是否会违反PUT的原则？无论如何，你应该考虑这些参数。但是如果参数与服务器端的值并不匹配，是否应期望得到一个“HTTP 409 冲突”（强制发出一个GET...）？如果对这些参数随机赋值，是否应寄希望于服务器会忽略它们（隐藏错误，乐在其中）？如果随便选定一个参数，显然 REST 对只读属性是毫无头绪的，并且这个问题并不会很快得到修正。同时，GET会返回之前由POST或PUT发送的密码（甚至是信用卡号），这是很危险的。如果一定要处理这样的只写参数，那么我只能祝你好运了。噢，我还忘了提及，PUT会带来的一些危险的竞争条件。虽然多位客户端只想各自更新一些不同的域，但可能会互相覆盖对方的更改。
文中对 REST 架构理念、错误处理及其它许多方面做了详细的评估，结果差强人意。对于那些 REST 支持者和不愿相信 REST 不足之处的人来说，这篇文章值得一读。Pakal 最后总结如下：
近乎透明的 RPC，这才是 99% 的人真正需要的。尽管现有的 RPC 协议不够完善，但是完全够用。大众对 Web 和 HTTP 最小共同处的偏执喜好，大多导致了在时间和一些灰色地带上的巨大浪费。REST 承诺简单性，但却交付了复杂性；承诺稳健性，却提供了脆弱性；承诺互操作性，却实现为异构性。REST 将步 SOAP 的后尘。
对这篇文章得到了大量的评论。显而易见，部分人同意 Pakal 的看法，但是绝大多数人持不同观点，并指出了 Pakal 的论点中存在许多缺陷。例如，Filippos Vasilakis评论到：
或许你应该看一下 Roy 的论文（译者注：指 Roy Thomas Fielding，他是 REST 架构的创立者，也是 HTTP 协议的主要编写人。在他个人网页上提供了博士论文全文）。你所攻击的，正是一些对 REST 的常见误解。正如 Roy 在论文中指出的，REST 可能并不适合所有的情况，但是非常适合于客户端无法控制的情况。所以，如果你知道任何有其它任何一个模型也是自描述性的、可演化的，请告诉我们。REST 具备上述所有特性，可与我们无法控制或不能控制的设备、客户端、硬件进行对话。这类似于在 Apple Store 中的移动应用需要 10 天才能部署新更改。如果你对应用的更新没有被 Apple 公司拒绝，你甚至不能访问或更新传感器设备等。类似情况下，我们可以使用 REST，乃至最近推出的、依然有很多限制和问题的 GraphQL。但如果你想出了另一个能解决可演化性问题的模型，请告诉我们。当然，RPC 不算在内。
另一个评论来自于Vlad Ko：
哎哟，我刚刚读了些什么呀！你是在抱怨浪费了时间去架构适用的 API 吗？我认为这正是你的责任所在，并且作为一名开发者，目标就是要确保提供适用的 API。在光天化日之下，抱怨每一个与 REST 相关或“无关”的问题，这有意义吗？太幼稚了～每种语言、协议、规范和概念都存在自身的问题和缺陷，诸如语法不合逻辑、虚拟机缓慢、缺乏类型支持、过于严格、过于松散、过于实用、缺乏足够的 OOP，等等。希望你能进入软件工程的世界看看。
这是一篇优秀的文章。内容颇具冲击力，提供了大量有支撑的事实，给出了合理而详尽的方式去阐明道理。但是，有一个因素在文中并未论及，就是工具。如果正如你在文章中所说，人们放弃了现在是或曾经是逻辑纯粹典范的 SOAP，这是因为一旦人们并非使用 Java 或者.NET 做工作，这时工具真的是非常糟糕。有人告诉我，工具已经改进了。但是如果人们感到痛苦，那么他们就会采用新的工具来应对这种痛苦。我认为，你的论点是想说明我们可能选择了一条不幸的道路，并应该继续前进，为什么要这样做？你引用了其它一些更现代的协议，但是我很好奇的是，你究竟能举出哪些可直接替代 SOAP 或 REST 的具体例子。
原文不仅引发了大量直接评论，也在各大社交媒体平台掀起了轩然大波。最终，WeWork 的平台工程师Phil Sturgeon以“对 REST 将步 SOAP 后尘的回应”为题目撰写了一篇文章。显然有很多人希望他能驳斥原文中的观点。
整篇文章充斥着对 REST 和 HTTP 的一些常见误解。尽管我的事业就是通过教育使人们摆脱各种混淆之处，但这些误解依然影响很深。显然，这是由于我的声音不够响亮，写得不够好，或是做得不到位。这是读者可能会在我的写作中看到的沮丧感，但并非针对原文作者。
和 Pakal 最初给出的文章一样，Phil 的回应同样是长篇大论。Phil 详细回应了 Pakal 指出的 REST 问题。例如，对于 Pakal 提到建造“残缺脆弱的车轮”，Phil 这样回应道：
好吧，这是令人沮丧的。REST API 往往为人嘲笑，因为支持者解释说人们不需要依赖于文档。REST API 当然不需要文档，但是我用最近几个月的时间，为我们的 API 生成文档，因为它们都是 RPC API。当一个 API表示自身的状态、使用超媒体声明其可供性并提供了一个合约时，你可以选择去生成可读的文档，但这只是针对那些将 REST API 作为 RPC API 看待的人…… REST API 的确需要更少的文档，除非你和为数不少的人一样，只是构建了一个未规范的 RPC 去冒充 REST。
Pakal 还探讨了PUT等 HTTP 动词中存在的风险。“听起来，这应该是由于不了解PUT的目的，进而产生的一种挫折感"。Phil 的剖析和回应内容很长。实际上，即使没有阅读 Pakal 的原文，Phil 的回应也值得一读。总而言之，文中的观点是，Pakal 对 REST 抱怨的绝大部分（即使不是全部的话）是由于他的误解所致。Phil 总结道：
我知道 REST 十分复杂。太多的人误以为自己理解了这个问题。一旦他们遇到了不了解的情况，就会给出错误的评判。世界各地的人们都在构建 REST 风格的 API，这些 API 基本上只是“RPC+HTTP 动词 + 一些漂亮的 URL”。这看起来并不是很有帮助，所以他们大书特书，解释为什么这样做不是很有用……
事实可能的确如此。但 Phil 和 Pakal 的争鸣似乎还在继续，因为我们看到 Phil 又进一步更新了讨论情况。
我依然在与作者进行着富有成效的对话，帮助他了解 REST 的工作机制。我想各位可能也会对此感兴趣。
欢迎各位有兴趣的读者围观，了解讨论的进展情况。
查看英文原文： REST is the new SOAP?
注册/登录 InfoQ 发表评论