我们是否需要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 Thrift、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?