后REST时代正在来临


现在,或多或少所有大型API都是RESTful。它会永远保持这种状态吗?似乎不太可能。下一个是什么?

REST是什么?
它通俗地用于表示任何基于HTTP的API。实际上,它们中的绝大多数都对具有URI的资源进行CRUD操作,因此在原始意义上可以说是RESTful; 虽然这些天我偶然听到“CRUDL”,其中L代表List。
在我工作的AWS,我们几乎总是在区分“控制面板”和“数据面板”。例如,考虑我们的数据库即服务RDS ; 控制面板应用程序是您创建,配置,备份,启动,停止和删除数据库的位置。数据面板是SQL,带有连接池和所有RDBMS行李。
有趣的是,控制面板非常漂亮,但数据面板根本不存在。(这不一定是数据库的事情:DynamoDB的数据面板非常RESTful。)
我觉得有一个模式:几乎控制面板都是REST风格的,因为,这就是你将要创建和删除的东西。数据面板可能是另一个故事; 我在这里的第一个预测是,无论什么是什么,只要能取代REST都将首先在数据面板上开始,因为控制平面和REST非常适合。

RESTful缺陷
我们想要超越REST的原因是什么?我列举一些:

  • 延时 :设置和拆除你想要做的每一个小小的操作的HTTP连接不是免费的。几十年的努力降低了成本,但仍然如此。很多使用MQ的原因之一是他们不想要 RESTful接口。
  • 耦合:多数REST请求同步运行; 也就是说,你通过(GET,POST,PUT,等等)调用,然后你必须停下来,等待到得到你的结果。现在您的请求可能会返回202 Accepted,在这种情况下,您可能希望发送一个URI以作为webhook回调,或者在您可以轮询的响应中获取一个URI。但在所有这些情况下,耦合仍然非常厉害: 调用者必须保持某种关于请求的状态,直到调用者完成它。
  • 寿命短 : 处理一些请求需要几毫秒。涉及大量的编排服务的,偶尔的人工交互则需要很长时间,让线程等待的想法是荒谬的。


关于GraphQL
由于RESTful接口倾向于很好地告诉您单个资源,因此可能会导致浪费的请求。因此,GraphQL允许您在单个请求中从多个资源中挑选任意选择的字段。据推测,服务器端实现会在数据中心内发出请求,这些调用更便宜,然后组装您的GraphQL输出,但无论如何这不再是您的问题。

关于RPC
这几天,我想我必须指的是gRPC。我不知道,我已经老了,我看到一代又一代的RPC框架惨遭失败; 脆弱,需要大量配置,并且无法实现预期的性能优势。闻起来就像让RESTful API更加紧密耦合,对我而言,很难看出这是一场胜利。但我可能是错的。

后REST:消息和事件
云基础设施会终结一切,你所要做的是通过消息和事件和其打交道。

后REST:编排 
其中“工作流程”是指跟踪具有多个步骤的计算状态的服务,其中任何一个步骤可能需要任意长时间,可能会失败,可能需要重试,其行为和输出会影响后续选择输出步骤及其行为。
越来越多(例如)Lambda函数不是提供请求和返回响应,而是在提供输入的工作流的上下文中执行,等待它们完成,并将其输出路由到更下游。

后REST:持久连接 ​​​​​​​
第一个是已经广泛部署的HTTP / 2,它允许您跨单个网络连接复用多个HTTP请求。智能地使用,它可以为您带来永久连接的一些好处。但它仍然与TCP密切相关,这有一些不幸的副作用,我不会在这里深入探讨,部分原因是因为这不是我深刻理解的事情。但我希望看到许多应用程序和服务从HTTP / 2中获得很好的价值; 在某些程度上,因为就客户端而言,他们仍在制作和响应之前的旧HTTP请求。
下一个步骤是QUIC,放弃TCP而支持UDP,同时保留HTTP语义。这已经在很多Google产品上投入使用。我个人认为这是一个非常重要的事情; HTTP如此成功的原因之一是它的连接是短暂的,因此在工作时遭受破坏的可能性要小得多。在HTTP世界中,您一次需要处理的最多是一个失败的请求,而连接断开只是可能发生的原因之一。UDP使得连接断开的问题消失。
当然,没有免费的午餐。如果您使用UDP,你不会得到TCP的TC。
​​​​​​​