写点什么

REST 是否会步 SOAP 的后尘?

2018 年 2 月 05 日

看新闻很累?看技术新闻更累?试试下载 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,以及很少为人关注的PATCHDELETE

你想使用PUT实现资源的更新?那好,但是在部分高高在上的规范中规定了,数据输入必须与由GET接收的数据表示保持一致。那么你应该如何处理由GET返回的大量只读参数(例如创建时间、最后更新时间、服务器生成的令牌等等)?如果你简单忽略了这些参数,这是否会违反PUT的原则?无论如何,你应该考虑这些参数。但是如果参数与服务器端的值并不匹配,是否应期望得到一个“HTTP 409 冲突”(强制发出一个GET…)?如果对这些参数随机赋值,是否应寄希望于服务器会忽略它们(隐藏错误,乐在其中)?如果随便选定一个参数,显然 REST 对只读属性是毫无头绪的,并且这个问题并不会很快得到修正。同时,GET会返回之前由POSTPUT发送的密码(甚至是信用卡号),这是很危险的。如果一定要处理这样的只写参数,那么我只能祝你好运了。噢,我还忘了提及,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,等等。希望你能进入软件工程的世界看看。

Christopher Patti 评论道:

这是一篇优秀的文章。内容颇具冲击力,提供了大量有支撑的事实,给出了合理而详尽的方式去阐明道理。但是,有一个因素在文中并未论及,就是工具。如果正如你在文章中所说,人们放弃了现在是或曾经是逻辑纯粹典范的 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?

2018 年 2 月 05 日 18:009085
用户头像

发布了 371 篇内容, 共 90.4 次阅读, 收获喜欢 174 次。

关注

评论

发布
暂无评论
发现更多内容

为什么 Bash 脚本总是不稳定?

柴锋

bash Linux DevOps 运维 Shell

LeetCode题解:66. 加一,新数组求和再翻转,JavaScript,详细注释

Lee Chen

LeetCode 前端进阶训练营

56张图入门操作系统——内功心法,适合所有程序员

执鸢者

前端 操作系统

跟我一起基于Karma搭建一个测试环境(下)

Jack Q

测试框架 前端进阶训练营 Karma

有一种自我欺骗,叫只为孩子

zhoo299

随笔杂谈 家庭

SpreadJS 纯前端表格控件应用案例:集成 Odoo提升企业ERP表格功能

Geek_Willie

开源 SpreadJS Odoo

9大训练营免费开营!阿里云大数据团队的独门绝学全在这了

Apache Flink

大数据 训练营

吃透Laravel的Ioc容器

书旅

laravel 容器 ioc

Week11

一叶知秋

《精益创业》摘要

孙苏勇

书摘 精益创业

搭载十代酷睿i7处理器,这台ROG冰刃4新锐拥有媲美台式游戏电脑的性能

最新动态

奈学:reaseShared共享式释放锁

奈学教育

共享锁

进击谷歌:多线程下程序顺序怎么稳定不乱?

架构师修行之路

数据结构与算法

Pulsar 联合 TiDB 推出大数据场景数据应用分析解决方案

Apache Pulsar

大数据 InfoQ Apache Pulsar #TiDB

法定数字人民币将成中国金融新名片

CECBC区块链专委会

数字货币 人民币

四种主要的 IO 模型

方明

Netty

一文吃透PHP进程信号处理

书旅

php Linux 信号

云原生架构的基石

soolaugust

Docker 架构 Kubernetes 容器 云原生

华为:新政务风口下加宽“护城河”

脑极体

核查框架新的选择

柿子

jsr-303 核查框架 butterfly

浅谈如何做好软件研发团队的盘点

大黄蜂

团队管理 技术管理

ST在keil下开发时候文件options配置的一些小技巧

良知犹存

嵌入式

“庆俞年”大战,真正受损的不是李国庆

北柯

创业 合伙人 创业者 互联网人 当当网

大厂面试必读,JAVA进阶神书《深入理解Java虚拟机》第三版更新内容全曝光!

华章IT

JVM 虚拟机 周志明 Java虚拟机 jvm调优

大数据技术发展(二):Hadoop 技术生态圈的发展

抖码算法

Java 大数据 hadoop 大数据技术 hadoop3

2w字 + 40张图带你参透并发编程!

cxuan

Java 后端 并发

Flink所需组件-1

小知识点

scala 大数据 flink 流计算

为什么一旦自己创业了,很难再回到公司去坐班?

北柯

创业 互联网 创业心态 上班 上班族

微服务-技术专题-设计原则AFK

李浩宇/Alex

浅谈技术管理之团队管理

大黄蜂

团队管理 技术管理

Python3 for ... else ...陷阱

王坤祥

Python Python PEP

REST是否会步SOAP的后尘?-InfoQ