restful rest_HATEOAS的RESTful服务。 REST：刷新器

restful rest

在这篇文章中，我们将介绍有关HATEOAS的RESTful服务的综合文章。 REST：刷新器。

1.简介

“不好了！请，不要再发表有关REST的文章！” 你们中的许多人可能会尖叫，这是正确的。已经出版了太多的教程，帖子，讨论和最佳实践，而再提出一个几乎没有任何意义。

坦白地说，对REST的理解因人而异。并非每个人都有时间（也有愿望）阅读Roy Fielding优秀论文的“ 代表性状态转移”（REST）一章，因此，对于许多REST而言，无论其含义如何，它基本上都是基于HTTP的API的代名词。但是， REST的一面大部分时间都处于黑暗中，毫无根据地被遗忘和忽略：超媒体。

2. REST体系结构约束

代表性状态转移（或简称REST ）不是规范，而是体系结构样式，指导分布式软件系统设计的一组原则和约束。按照REST架构风格设计的系统必须符合五个强制性（和一个可选性）约束。让我们简要浏览一下它们。

客户端服务器
在微服务时代，这听起来很明显。但是，只是为了重申这一基本原理，客户端和服务器是相互分离的。这样，每一方都有能力和机会独立发展。

无状态
客户端和服务器之间的通信应该是无状态的。实际上，这意味着从客户端到服务器的每个请求都必须包含处理该请求所需的所有信息。服务器不应存储任何与会话相关的状态或上下文，因此客户端是负责管理该状态或上下文的服务器。通常将这一原理作为构建可靠的和水平可伸缩系统的必要先决条件。

快取
服务器必须能够向客户端提示响应中的数据是否可以缓存。高效的缓存实现可以减少服务器的不必要负担，提高整体可伸缩性，并显着减少网络交互的延迟。

分层系统
这又一个基本原则主张将体系结构设计为由层次结构层组成。在客户端/服务器通信方面，客户端无法确定它是直接连接到服务器还是通过任何中介连接（首先想到的这种中介是负载均衡器）。

统一界面
在我们的讨论中，这可能是最重要的体系结构原理，它强调组件之间存在统一接口。反过来，它概述了此类接口应遵循的五个约束：
- 资源识别

按需编码（可选）
此可选约束建议可以通过从服务器下载并执行一些代码来扩展客户端功能。

为了进一步加强它， REST为架构师和系统设计了一套原则和约束，但这绝不是实现。

3. REST！=通过HTTP进行RPC

REST体系结构样式不会将客户端/服务器通信限制为特定协议。但是，如今，它主要用于构建通过HTTP （ Web协议）进行通信的Web API和服务。

在这种情况下，使用URL标识各个资源。 JSON或XML是表示资源的两种主要格式，而客户端可以使用适当的HTTP动词来操纵资源。坦白地说，大多数Web API设计人员和实施人员就此止步，根本没有提及HATEOAS 。所有这些人是否会误解REST的含义？罗伊·菲尔丁（ Roy Fielding）在他的一条推文中很好地总结了这一点：

我不同意这个术语的流行理解是不同的。不同的是某些公司，作者和发言人希望在知道仅是HTTP时说REST；不是因为他们不知道该术语的含义，而是因为$$$ >>的含义。
https://twitter.com/fielding/status/1108092713516163072?lang=zh-CN

它总结了业界对REST体系结构样式采用的悲观状态。是的，它似乎无处不在，但是不幸的是，大多数Web应用程序使用RPC样式而不是遵循REST明确定义的约束（尤其是统一接口 ）通过HTTP在HTTP上公开了这些API和服务。

这是为什么？可能的部分原因是， REST体系结构样式提到了超媒体和HATEOAS，但并未真正说明必须完成的精确度（考虑了客户端和服务器之间可能发生的所有复杂交互）。

在某种程度上，人们误解了REST，因为我没有在论文中包含关于媒体类型设计的足够细节。那是因为我没时间了，不是因为我认为它比REST的其他方面都重要。
https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-724

同样，对于许多人来说，不仅要设计资源命名，表示，语义和操作，而且还要设计状态转换（甚至不涉及测试所有主题），似乎是一笔不小的开销。

但是，我认为大多数人都犯了一个错误：设计简单的东西应该很简单。实际上，设计某些东西所需的工作与结果的简单程度成反比。随着建筑风格的发展，REST非常简单。
https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-724

我认为遵循REST架构风格值得付出努力。是的，您可能不知所措。是的，由于不适合您的编程语言或平台的工具和库，您可能会面临很多挑战，尤其是在超媒体方面。另一方面，您最终将获得描述性强，易于理解和可维护的Web服务和API。

在输入REST API之前，除了初始URI （书签）和适用于目标受众的标准媒体类型集（即，期望使用该API的任何客户端可以理解的标准媒体类型）外，都应该没有其他知识。从那时起，所有应用程序状态转换都必须由客户端选择服务器提供的选择来驱动，这些选择出现在接收到的表示中或由用户对这些表示的操纵来暗示。过渡可以由客户端对媒体类型和资源通信机制的了解来确定（或受其限制），这两者都可以动态地（例如，按需编码）进行改进。
https://roy.gbiv.com/untangled/2008/rest-apis-must-be-超文本驱动

希望在本教程的过程中，我们将揭穿一些神话，并以实际方式证明HATEOAS支持的Web服务和API是可行的，而且并不难。

4.巨大的困惑：RESTful与REST

由于许多组织和个人正在使用自己对REST的解释来构建Web服务和API，因此导致人们对哪种应用程序和系统实际上遵循REST体系结构风格感到困惑。为了使这种区别显而易见， RESTful这个术语诞生了。

遵守REST体系结构约束的 Web服务API称为RESTful API。
https://zh.wikipedia.org/wiki/Representational_state_transfer

本质上，此定义没有余地：满足所有必需的约束，或者请不要将您的API称为RESTful 。毫不奇怪，罗伊·菲尔丁（ Roy Fielding）对这件事有更严格的意见。

要使REST体系结构风格清晰地认识到超文本是一种约束，需要采取什么措施？换句话说，如果应用程序状态的引擎（以及API）不是由超文本驱动的，则它不能是RESTful的，也不能是REST API。期。是否有一些需要修复的故障手册？
https://roy.gbiv.com/untangled/2008/rest-apis-must-be-超文本驱动

本教程的目的是展示HATEOAS是头等公民的RESTful API设计以及所有其他必需的约束。不，我们不会将REST视为宗教，而是要证明每个元素都很重要而且存在是有原因的。