我们是否需要 REST 的替代品？

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?