HarmonyOS开发者限时福利来啦!最高10w+现金激励等你拿~ 了解详情
写点什么

REST 是否会步 SOAP 的后尘?

  • 2018-02-05
  • 本文字数:3184 字

    阅读完需:约 10 分钟

看新闻很累?看技术新闻更累?试试下载 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-02-05 18:0011094
用户头像

发布了 391 篇内容, 共 135.1 次阅读, 收获喜欢 256 次。

关注

评论

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

FonePaw Data Recovery for Mac:专业的数据恢复方案

iMac小白

浅谈云主机在VPC中进行迁移的使用场景和操作方法

天翼云开发者社区

云计算 云主机

浅析MySQL代价模型:告别盲目使用EXPLAIN,提前预知索引优化策略| 京东零售技术团队

京东科技开发者

详解Python 中可视化数据分析工作流程

华为云开发者联盟

Python 数据可视化 华为云 华为云开发者联盟 企业号2024年5月PK榜

基于LangChain实现数据库操作的智能体

测吧(北京)科技有限公司

测试

算法人生(15):从“智能任务调度算法”到“15-45-90时间管理法”

养心进行时

人工智能 算法 时间管理 智能调度

天翼云助农上演“科技大片”,绘就数字春耕新图景!

天翼云开发者社区

云计算 云电脑

OmniPlan Pro 4 for Mac v4.8.1中文激活版:项目管理的新选择

iMac小白

OmniPlan Pro 4下载 OmniPlan Pro 4破解版

【京东云新品发布月刊】2024年4月产品动态

京东科技开发者

解构复合人工智能系统(Compound AI Systems):关键术语、理论、思路、实践经验

Baihai IDP

程序员 AI LLM 白海科技 企业号 5 月 PK 榜

这款工具让开发变得没门槛了

Tp_jh

容器 云原生 K8s 多集群管理 云端开发 生成式AI

算法人生(11):从“梯度提升树(GBDT)”看“2/8时间管理法”

养心进行时

机器学习 算法 时间管理 梯度提升树 GBDT

算法人生(10): 从“惰性求解”看“积极拖延”如何提高效率

养心进行时

算法 拖延 惰性求解 算法思路

算法人生(13):从“Scrum”看“PDCA时间管理法”

养心进行时

Scrum 敏捷 时间管理 PDCA 敏捷项目管理

谈谈天翼云对等连接

天翼云开发者社区

云计算 天翼云

实“智”名归!天翼云论文被国际顶会IEEE CVPR收录!

天翼云开发者社区

人工智能 云计算

一招MAX降低10倍,现在它是我的了| 京东零售技术团队

京东科技开发者

pandabuy VS wegobuy 淘宝代购集运系统类似软件哪家公司开发的?

tbapi

淘宝代购系统 淘宝代购集运系统 Pandabuy wegobuy

新一代多模态合规分析平台,炼就服务洞察火眼金睛

中关村科金

人工智能 多模态 大模型 客户洞察

基于LangChain实现数据库操作的智能体

测试人

软件测试

算法人生(12):从“优先级队列算法”到“”六点优先工作法”

养心进行时

人工智能 算法 优先队列算法 六点优先工作法 工作方法

EndNote 21 for Mac 大客户授权(文献管理软件)v21.3永久激活版

iMac小白

EndNote for Mac EndNote 21 EndNote 21下载 EndNote 破解版

Remote Desktop Manager for mac(远程桌面管理器)v2024.1.8.6中文激活版

iMac小白

算法人生(14):从“探索平衡策略”看“生活工作的平衡之道”

养心进行时

人工智能 平衡 强化学习 探索平衡策略

以数字守护汉字!天翼云TeleDB数据库获GB 18030最高级别认证!

天翼云开发者社区

数据库 云计算

7个维度告诉你,产品经理是如何取舍“需求”的?

养心进行时

需求管理 需求 需求迭代

Paste Queue for Mac(剪切板管理工具)v1.6.2永久激活版

iMac小白

Paste Queue下载 Paste Queue破解版 Paste Queue激活版 Paste Queue mac

PowerPhotos for Mac(mac专用图片管理工具)v2.5.8直装版

iMac小白

PowerPhotos下载 PowerPhotos直装版 PowerPhotos激活版 PowerPhotos mac

Multitouch for Mac激活版下载:触控板手势增强软件

iMac小白

REST是否会步SOAP的后尘?_REST_Mark Little_InfoQ精选文章