SoapUI 的缔造者 Ole Lensmar 最近被问起,是否认为 REST 即将步入暮年,以及是否需要寻找它的替代者。对此他表示:
在近些年中,REST 得以成为构建公用 API 的主要方法,并令任何其他 API 技术或方法都黯然失色。虽然在企业中依旧(非常)流行一些其他方法(主要是 SOAP),但是 API 运动的早期参与者们已经抱有鲜明的立场:他们选择了 REST 方法,并以 JSON 作为首选消息格式。
接下来,Ole 探讨了为何他认为 REST 比其他方法(例如 SOAP 和 XML-RPC)更加成功。尽管如此,Ole 也承认在一些领域中 REST 确实表现不佳,需要使用其他替代者来应对这些应用场景下的需求。这些领域包括:
- 异步 API:“面对用异步推送数据取代传统请求 / 响应模式的需求,RESTful 设计并不适用。此外,底层技术(例如 WebSockets、MQTT、AMQP、Stomp、pubsubhubbub/WebHooks 等)常常与 HTTP 有很大不同,因此往往也就不能与 REST 准则良好匹配。”
- 编配 API:“传统 REST API 提供的资源粒度并不总是一项优势;将资源拖入移动仪表板或是复杂的单页 Web 应用,将需要许多 API 请求——这将同时增加客户端逻辑、带宽和服务器处理方面的开销。”
- SDK vs API:“大部分使用者最终都是在一些高级语言中调用 API;诸如 JavaScript、Python、Ruby、Java 等等,因此许多 API 提供者都为这些语言提供了预建的客户端库(Google、Facebook 等)。这些语言本身往往更加面向 RPC,由 SDK 暴露出的代码层面的 API 也是如此——因此,要让后端 API 采用相似的方式工作,或许需要使用更加优化的二进制协议(见后文)或是与 RPC 更加类似的 HTTP 资源的使用(例如 JSON-RPC)”
- 二进制协议:“[……] 面对 IoT 设备或 SDK 中的要求——例如传输优化后的消息——若干二进制协议正在获得更多的关注并得到运用”,例如 Apache Thrif t、Google Protocol Buffers 和 Apache Avro.“[值得一提的是] 上面提到的若干异步 API 技术使用一种二进制格式——与带宽和来自其存留的设备或服务的处理约束有关。”
Ole 以 Evernote(在大陆地区的产品名为印象笔记)为例,它使用 Thrift 作为其底层协议,以应对实时请求(这大概也是 Ole 所指的超出 REST 能力的东西)。他提到了另一篇由 Daniel Jacobson 撰写的关于 Evernote 的 RESTless 设计的独立文章:
[……] 当我们面对大量未知的开发者时,REST API 或许是个好的选择——然而当我们的 API 针对非常明确的用户、市场、行业或技术时,对于更加具体的解决方案的需求并不是毫无来由的——或许这甚至会使我们在性能、易用性或安全性方面领先我们的竞争者。
在总结中 Ole 表示,万应灵药并不存在,特别是与 API 设计有关的领域。“幸运的是,对我们这些热忱的技术人员来说,构建和学习新东西,并尽可能让所有利益干系人都运用它,将使我们的世界(至少是我的)充满活力。所以我并不反对这种多样性,相反我很乐于见到这一切。”
然而,虽然得到了一些人的赞同,但是也还有许多人对 Ole 的观点表示反对。例如 John Sheehan 说:
我并不认为 Evernote 称得上是“放弃了 REST”,因为他们自始至终都没有使用它,并且有充分的理由这样做。同时,Webhooks 也可以是非常“REST”的(至少从对这一概念的通俗理解来看是这样)。Ole 在异步这部分列出的警告,并不适用于大部分常见的实现。
而 Darrel Miller 则试着区分 REST 和“pop REST”:
从 Daniel Jacobson 对编配层的描述,我认为它与我在过去数年间一直采用的 RESTful(以及超媒体驱动)API 构建方式贴合地非常紧密。只不过因为人们开始识破“pop REST”的大肆宣传,并不意味着 Fielding 所定义的 REST 的属性已经发生了变化。
实际上许多评论家相信,Ole 没有真正将 RESTful 原则,与打着 RESTful 旗号但实际却并非如此的实践进行区分。各位读者对此怎么看?在 Ole 所列举出的全部领域中 REST 是否真的适用?如果不是的话,你推荐用什么来替代它?
查看英文原文: Are REST Alternatives Needed?
评论