后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。

​​​​​​​