PCon全球产品创新大会最新日程上线,这里直达 了解详情
写点什么

REST 是否会步 SOAP 的后尘?

  • 2018 年 2 月 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 年 2 月 05 日 18:009222
用户头像

发布了 386 篇内容, 共 103.7 次阅读, 收获喜欢 240 次。

关注

评论

发布
暂无评论
  • 工整与自由的风格之争:SOAP 和 REST

    它们来自两个不同的时代,却同时活跃于当今的互联网,并担当着重量级的角色,影响了一批新技术的诞生。

    2019 年 9 月 18 日

  • 争论:REST 需要描述语言吗?

    追踪上周在此讨论的关于REST vs. WS-*的争论,值得注意的是,以REST化服务契约为主题的争论在最近几天日嚣尘上。

  • API 开发者永不“REST”

    尽管HTTP是一个应用层(例如,L7)协议,但在API开发方面,HTTP实际上扮演着一个较低层次的传输机制的角色。

  • 文章:描述 RESTful 应用程序

    如果服务器不将它自己的名字空间控制在一个固定的资源层次下,客户端及更重要的客户端开发者将如何知道或发现资源的URI呢?在这篇新文章中,Subbu Allamaraju对如何描述RESTful API进行了讨论,文章重点集中于超媒体而不是诸如WADL或WSDL 2.0这类带外(out-of-band)描述格式的使用上。<a href="http://www.infoq.com/cn/articles/subbu-allamaraju-rest" target="_blank">直接点击阅读完整文章</a>。

  • WebSockets 与 REST 之争?

    随着WebSockets目前成为W3C的推荐候选,以及一个新JSR将会在JCP中启动,很多人不禁要问WebSockets是如何在REST协议下运作,那将是会怎样的情景?两者彼此是否兼容,或许正如有些人相信的那样,WebSockets是否会将公众的注意力从REST转移过去,从而引领一种新的Web交互风格?甚至已经有人认为,WebSockets将会“破坏web”。

  • API 风格(上):如何设计 RESTful API?

    今天,我们一起来看下如何设计应用的API风格,我会介绍两种常用API风格中的一种,RESTful API。

    2021 年 6 月 22 日

  • 超越轮询?考虑 PubSub、Push 和 MOM

    如果你指望这篇题为《超越REST?使用XMPP PubSub构建数据服务》的幻灯片会让REST的拥护者竭力反对,那就大错特错了。实际上,它是围绕不同PubSub方案的优缺点展开了讨论。

  • Web 风格起过作用吗?

    大约七年前,Tim Bray 宣称SOA已经离死期不远,而Web风格才是未来的趋势。但是在最近的一篇博客文章里,Jean-Jacques Dubray回顾了这几年来Web风格的发展趋势,并且断定Web风格从未起到过作用,不仅如此,在可编程的Web目录里还涌现出了大量的非Web风格的服务,而从这种趋势看来,实际上是Web风格要灭亡了。他还就这一现状对于计算技术和应用开发的未来意味着什么进行了考虑。

  • 安全:防开放重定向攻击

    2020 年 4 月 27 日

  • 什么时候 POSTing 状态合适?

    在这篇文章中,Tim Bray,审视了Sun Cloud API的第一版公众草稿所收到的反馈。对于其中一些反馈他在文中作出了回应,对于如何对交互进行建模,例如以RESTful的方式创建一个VM集群,进行了探索。

  • JAX-RS,或者说 RESTeasy 不是 RESTful?

    JAX-RS是用Java编写RESTful应用程序的标准方式。然而,最近restfulie项目的领导Guilherme Silveira——这不是一个基于JAX-RS的项目——却对RESTeasy和JAX-RS是否是RESTful提出了质疑。

  • Internet 比 REST 更基本吗?

    REST是否优于WS-*的争论已经僵持一段时间了,没有明显的赢家。然而,Ganesh Prasad试图给争论火上浇油,并举例说明他始终不认为REST是最基本和可扩展的方法。

  • 持续演进,克服“REST 缺乏”

    新的API协议(如GraphQL、gRPC和Apache Kafka),作为受REST启发的HTTP API的替代品,越来越受到欢迎。

  • 专访和样章试读:RESTful Web Services

    InfoQ发布了由Leonard Richardso和Sam Ruby联合撰写的“基于REST的Web服务”一书的样本章节。该书介绍了REST架构的原则,并解释如何使用Ruby on Rails、Restlel和Django构建基于REST 的应用。借此机会,InfoQ的Stefan Tilkov采访了该书作者,讨论关于写作该书的背景以及他们对REST和Web服务的看法。

  • 学员梁志杰:被问题难倒想转行,我是怎么解决的?

    技术路上一个人走会有很多坑,有些坑很难,难得让你会想放弃,甚至真的放弃了,这些我经历过,太懂了。

    2021 年 3 月 16 日

  • 接口规范,是协作的合约

    对于接口规范,我们要有意识地使用下面的这条原则:接口规范是使用者和实现者之间的合约。

    2019 年 2 月 1 日

  • unREST 是新的 REST 吗?

    Jean-Jacques Dubray在他最近的一篇文章中讨论了为什么我们应该跳出REST的圈子,也许应该同意在很多目前正使用REST的领域中,REST其实并不适用。在试图描绘他认为的发展方向时,他提出了unREST,即3条设计成功API的简单规则。

  • 请不要再管它们叫 REST API 了

    只是简单地将 CRUD 操作映射到 HTTP 动词的 API 与应用程序状态转移丝毫扯不上关系,你可以把它们叫作 Web API 或 HTTP API,但请不要把它们叫作 REST API。

  • 我应该迁移到 HTTP/2 吗?

    我们是否应该迁移到HTTP/2,又应该如何迁移到HTTP/2呢?

    2019 年 8 月 12 日

  • Roy Fielding 谈 Google SPDY 协议

    近日Google SPDY协议成为了热门话题,甚至有很多人认为SPDY协议即将成为HTTP/2.0。那么HTTP/1.1协议的作者Roy Fielding对SPDY协议有何评论呢?这是一个让国内众多Web开发者感兴趣的问题。

发现更多内容

[架构师训练营第 1 期] 第 13 周命题作业

猫切切切切切

极客大学架构师训练营

架构师训练营 2 期 Week09 作业

CJian

成为架构师 - 架构师训练营第 08 周

陈永龙Vincent

架构师训练营第二期 Week 9 作业

bigxiang

极客大学架构师训练营

架构师训练营第二期 Week 9 总结

bigxiang

极客大学架构师训练营

大数据应用

garlic

极客大学架构师训练营

第十三周作业

orchid9

【架构师训练营第 1 期 13 周】 学习总结

Bear

极客大学架构师训练营

第十二周作业

TheSRE

极客大学架构师训练营

周练习 13

何毅曦

week13作业

追风

架构师一期

架构师 01 期,第十三周课后作业

子文

架构师训练营第 1 期 -- 第十三周作业

发酵的死神

极客大学架构师训练营

架构师训练营第2期 第9周总结

月下独酌

极客大学架构师训练营

成为架构师 - 架构师训练营第 07 周

陈永龙Vincent

架构师训练营第九周笔记

李日盛

架构师训练营 2 期 Week09 总结

CJian

第十三周 数据应(二)作业

钟杰

week13学习总结

追风

架构师一期

C语言学习你要的都在这里

C语言与CPP编程

c++ 学习 编程 C语言

JVM&秒杀案例

幸福小子

JVM原理

架构师训练营week13 作业

FG佳

极客大学架构师训练营

架构师训练营 week13总结

FG佳

极客大学架构师训练营

架构师系列 10: JAVA 虚拟机的原理

桃花原记

架构师训练营 - 第 13 周课后作业(1 期)

阿甘

【第十三周】数据应用(二)

云龙

第十三周总结

orchid9

训练营第九周作业

大脸猫

极客大学架构师训练营

训练营第九周总结

大脸猫

极客大学架构师训练营

第九周作业

Jack

JVM垃圾回收原理

幸福小子

JVM垃圾回收原理

ShadowRealm 与微前端沙箱

ShadowRealm 与微前端沙箱

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