如今，随着架构的解耦和微服务架构的兴起，每个开发者都不可避免地要使用REST来构建API，并与REST进行交互。但是我们真的了解并利用好当代休息和超媒体的好处吗？本文将在2020年和你、休息、超媒体一起学习。

概述

这可以通过几种方式实现，主要依靠RESTAPI所在协议的现有语义，通常是HTTP。在HTTP中构建RESTAPI，我们应该遵循现有的HTTP语义来实现REST提出要实现的概念，而不是发明自己的约定。

客户端可以查询Retry-After头并自己处理错误代码，而不是编写一堆代码来理解API可能响应的每个应用程序错误。

开发人员抱怨REST很难，因为需要理解HTTP方法及其含义，以及不同的状态代码。虽然学习HTTP可能需要一些时间，但是HTTP的约定是与一个巨大的工具生态系统共享的。

开发人员一贯拒绝这些技术，很多时候他们更喜欢RPC。对于很多开发者来说，在互联网上运行这些API就足够了，他们可以在上面添加自己的操作和约定。这样虽然他们获得了一些需要的函数CRUD (post，get，put，delete=create，read，update，delete)，但是却失去了很多REST架构所能提供的好处。

REST是RPC之上的一堆抽象层？

理查森的成熟度模型结构如下所示：

这是MartinFowler文章介绍《Richardson成熟度模型》的总结图。该模型以LeonardRichardson命名，讨论了API的成熟度。

这个图有一些常见的问题，主要是上面是‘gloryfrest’，下面是一团乱。不幸的是，这使得RESTAPI看起来像一个迷宫，其他一切都是一团糟。

休息的好处显而易见：

网络上的一切都可以抽象为一种资源(unify)；

每个资源有一个统一和唯一的资源标识符(URI)；

使用标准方法操作资源；

所有操作都是无状态的；

您可以通过缓存来提高性能。

另一个问题是Martin说的是PlainOldXML。现在有人在说POJO(PlainoldJSONObjects)。

API规范(用于描述数据模型的元数据)可以被所有的API开发者使用，不管他们的例子或者选择的实现，所以他们应该被考虑。REST人员用JSONSchema，gRPC人员用Protobuf，GraphQL用户有GraphQL类型。

在

改进Richardson成熟度模型

RPC

真正的问题是，最基本的RPC形式通常忽略了许多HTTP概念。它不使用HTTP的统一接口及其完整的语义，也不使用HTTP作为传输协议，只使用传输方面。传输协议可以帮助您知道何时或是否需要发出请求，而不仅仅是在网络上传输数据。大多数RPC实现与单个端点交互，并且大多数交互使用单个HTTP方法。很少有通用的HTTP约定只能用于最基本的RPC。

如果RPC遵循特定的标准，您可以使用为该标准构建的工具，但是通用的HTTP约定并不适用。

资源

这里有两个常见的困惑。第一，这不是拥有/bikes、/bikes/abc123，而是常用的标准集、复数和资源CRUD模式。

从技术上讲，资源和端点是同一个东西，但有一个故意的区别。端点通常被认为更像函数，其目的是在想要做某件事的时候调用某个函数，但这是最具传输性的传输方式，这通常是RPC思维的标志：调用某件事，执行某件事。

资源更像是一个标识符。它是特定位置的唯一事物，并且能被那个事物识别。它是HTTP世界中最终的唯一标识符，尽管可能有不同的产品具有相同的字母数字ID，并且UUID也可能冲突。

URI(统一资源标识符)对于所有内容是唯一的。这样，我们可以为不同的资源添加特定的头，这些头可以作为元数据存储在响应中。

这样，资源可以声明自己的可缓存性,这是REST的重要内容之一。

缓存约束要求请求响应中的数据隐式或显式标记为可缓存或不可缓存。如果响应是可缓存的，则客户端被授予缓存和重用响应数据的权利，以供将来的等效请求使用。

添加缓存约束的优点是，它可以通过减少一系列交互的平均延迟来部分或完全消除某些交互,从而提高效率、系统可扩展性和用户感知的性能。

HTTP/1.1中缓存的目标是通过重用以前的响应消息来满足当前请求，从而显著提高性能。如果响应可以在没有“验证”的情况下重用，则存储的响应被认为是“新鲜的”(检查原始服务器以查看缓存的响应对于请求是否仍然有效)。因此每次你。

如果具有唯一的URI，则在HTTP/2中也无痛升级使用。

HTTP方法

方法为请求中发生的事情的类型添加了许多重要的语义。如果使用了缓存，则缓存组件将知道它可以缓存GET请求，但是如果对同一个资源执行POST或DELETE操作，它将知道它应该避开它。

像自动重试这样的客户端逻辑现在成为可能。当API花费很长时间进行响应时，重试可以提供帮助，客户端应用程序可能会针对请求进行保释，然后重试。使用GET几乎没有什么缺点，它是幂等请求，不应具有任何破坏性动作。

重试POST可能很危险，因为可能在达到超时之前，它可能会更改数据库中的某些记录，发送一些电子邮件，从信用卡中收取费用等。

PUT和PATCH会很好，PUT也是幂等的，只会消除结果，并且PATCH通常具有"from"和"to"，这意味着如果第二次发出请求，则"from"可能会不匹配。

对RPC的忠实拥护者，！gRPC"HTTP桥"添加了这两个抽象层，使其更加像HTTPish。

超媒体控件

超媒体控件是"超媒体作为应用程序状态引擎"（HATEOAS）的简写，它是一个非常简单的概念。API不仅仅是HTTP上的数据存储，而是成为HTTP上的状态机。它仍然有数据，但是它也可以以自我描述的方式提供"下一个可用动作"。

考虑一张发票，说它是可付款的，而不是需要根据缺少来确定是否可以付款paid_date，或者可能有status:pending，但是可能会添加新的状态并等待处理并不意味着可以付款。客户应用程序中断或需要版本控制，这两者都会浪费开发人员时间和公司资金。

如果发票是应付账款，则会显示一个名为"付款"的链接，这表示客户端应用程序知道何时付款，并且只要使用了良好的超媒体格式，客户端应用程序就会知道如何付款，因为控件可以向服务器发送HTTP请求之前验证数据客户端，给出哪些数据是必须要提供的。

超媒体的最基本层次是将链接推到响应主体中，但是客户端必须做很多验证工作才能弄清楚下一步该做什么。此前，只会是："你有一个URL和一个链接关系，这是一个很好的开始"，但是如今，有很多流行的HypermediaFormats使这一切变得容易得多。

REST

大多数自称为REST的API都没有最后一层，这意味着它们使用的仅仅是RESTish，或者仅仅是HTTPAPI。因为没有超媒体控件，就不能叫RESTAPI，这很重要。

可能开发人员根本不知道HATEOAS(超媒体即应用状态引擎或超媒体约束)是什么。还有一些人知道，但是认为HATEOAS就是要强迫进行HTTP请求负载以获取相同数量的数据。这时他们考虑的是传输而不是转移，到了时下快要普及的HTTP/2，即使需要进行"更多调用"，性能影响也可以忽略不计。

即使到了REST这一层，也不意味着API会在所有方面都永远可靠且完美。粗劣的资源设计会使任何API都难以使用，不论你使用的是哪种范例。GraphQL开发人员现在开始注意到这一点。

专注于满足客户需求的模型设计非常重要，API会随着时间的推移而发展，修剪掉无用的数据，并创建复合资源以最大程度地减少不必要的网络延误。JSONSchema也刚刚弃用了一个关键字，这可以使API的开发变得更加容易。

超媒体和gRPC或GraphQL

在谈论超媒体控件时，常有这样的观点，比如"这不仅是REST可以做的事情，如果使用HTTPBridge并添加了链接，gRPC可以做到这一点！"

一段时间以来，著名的GraphQL开发人员一直在尝试找到一种将超媒体控件引入GraphQL的方法。如果他们能解决这个问题，GraphQL不会准确地遵循下面这个图，但我们可以调用query和mutation他们分享有或没有语义足够靠近HTTP方法和唯一缺少的是资源（URI）来。

对于GraphQL，缺少URI是一个更大的问题，这几乎破坏了他们直接使用HTTP/2ServerPush的机会，他们不需要向供应商寻求特定的解决方案，例如Apollo订阅和其他非标准@defer类型的东西。

总结

无论如何，API并不总是需要超媒体控件。例如，全栈开发人员经常认为REST浪费时间，因为他们只是想要查询数据库并将信息传递到表示层。他们不需要将缓存控件附加到消息本身中，他们只需要在客户端应用程序中设置缓存即可，该客户端应用程序可能在其计算机上的另一个窗口中打开。他们知道何时使用重试，因为他们编写了应用程序代码并知道它们的含义，因此他们不在乎是否使用了HTTP语义。这些开发人员与试图向可能位于不同楼层或不同大陆的各种客户团队提供一致功能的开发人员完全没有共同之处，在这些客户团队中，传达变更或如何推断状态可能是一个代价高昂的问题。这些团队可能正在使用各种网络和客户端工具，例如缓存中间件，服务监控，代理检查，并且不能限制他们可以使用的工具，因为这可能会使他们丢掉业务。

两者之间还有其他所有完全有效的方案。并不是所有的汽车都需要防弹玻璃，并非所有的对话都要有麦克风，不是所有的内衣都需要有吊带。同理，也不是所有的API都需要是REST。