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

素颜马尾好姑娘i 2023-02-25 03:56 24阅读 0赞

restful rest

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

## 1.简介 ##

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

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

### 目录 ###

1.简介 2. REST体系结构约束 3. REST！=通过HTTP进行RPC 4.巨大的困惑：RESTful与REST 5.理查森成熟度模型 6。结论 7.接下来

那么，这本书的背后的想法是什么？ 本教程的唯一目的是重温根源，重新考虑遵循[REST][]体系结构样式设计和实现Web API的含义，以及如何在Java服务和应用程序中或通常在JVM平台上实际实现Web API。 。

## 2. REST体系结构约束 ##

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

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

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

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

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

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

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

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

## 3. REST！=通过HTTP进行RPC ##

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

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

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

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

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

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

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

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

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

## 4.巨大的困惑：RESTful与REST ##

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

> 遵守[REST体系结构约束的][REST 2] Web服务[API][]称为[RESTful][REST] API。
> 
> [https://zh.wikipedia.org/wiki/Representational\_state\_transfer][REST]

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

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

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

## 5.理查森成熟度模型 ##

[REST][]保护下的Web服务和API的碎片要求采取行动。 作为响应， [伦纳德·理查森][Link 4] （ [Leonard Richardson）][Link 4]开发了API成熟度模型（通常简称为[Richardson成熟度模型][Richardson] ），该[模型][Richardson]实质上定义了4个级别的API成熟度。

![RESTful服务-Richardson API成熟度模型][RESTful_-Richardson API] 理查森API成熟度模型

这个非常简单的模型有助于轻松地确定特定Web API在实现[RESTful][REST]方面所处的位置（请注意，每个级别都基于其下一个级别）。 您可能还会注意到，该模型并非普遍适用，而是明确关注基于[HTTP][]协议的[REST][] （我们记得， [REST][]体系结构风格与基础网络协议无关）。

*  **0级– POX沼泽**  
    最底层是使用[HTTP][]协议进行远程交互以隧道请求和响应的Web API。 通常，他们使用单个[HTTP][]方法（通常是**POST** ）并公开单个API入口点。 这是典型的[RPC][] over [HTTP][]样式。

*  **级别1 –资源**  
    稍微成熟一些，我们会遇到一些Web API，这些API公开了多个入口点，或者遵循[REST][]命名法提供了单独的资源。 当然可以，但是这些API仍使用单个[HTTP][]方法（通常是**POST** ）。

*  **2级– HTTP动词**  
    为了更进一步地遵守[RESTful][REST]原则，此级别的Web API使用[HTTP][]谓词语义来区分各个资源上的不同动作。 这是大多数现代Web API最终达到的级别，声称“足够好”。

*  **3级–超媒体控件**  
    在最顶层，我们遇到了使用[HATEOAS][Link 2]和超媒体控件来引导客户端/服务器交互的Web API。 在此级别上，API可以称为真正的[RESTful][REST] 。

有了这个成熟度模型，每当您听到“……在我们组织中，我们构建暴露[REST][] Web API的应用程序……”时，我们很可能在谈论**Level 2** 。

## 6. RESTful服务–结论 ##

在本教程的介绍性部分中，我们更新了对[REST][]体系结构样式的了解，尤其是重新介绍了其强制性原则和约束。 我们还揭开了[RESTful][REST]一词的起源以及它如何应用于现代Web API和服务的神秘感。 再一次， [罗伊·菲尔丁][Roy Fielding] （ [Roy Fielding）][Roy Fielding]将其[牢牢地][Roy Fielding]钉牢了。

> 通过包含超文本的自描述消息的统一接口提供基于网络的资源访问的API，该消息包含超文本以指示潜在的状态转换，它可能是[RESTful][REST]应用程序的整个系统的一部分
> 
> [https://twitter.com/fielding/status/1125438763507654658][https_twitter.com_fielding_status_1125438763507654658]

在本教程的[后续][Link 2]部分中，我们将大部分时间花在谈论[HATEOAS上][Link 2] ，这可能是所有声称被称为真正的[RESTful的][REST] API中最困难但也是功能最强大的元素。

## 7.接下来 ##

在本教程的下一部分中，我们将开始讨论使用[HATEOAS][Link 2]功能丰富您的Web服务和API的多种方法。

> 翻译自: [https://www.javacodegeeks.com/restful-services-with-hateoas-rest-the-refresher.html][https_www.javacodegeeks.com_restful-services-with-hateoas-rest-the-refresher.html]

restful rest

[REST]: https://en.wikipedia.org/wiki/Representational_state_transfer
[Roy Fielding]: https://en.wikipedia.org/wiki/Roy_Fielding
[REST 1]: https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
[HTTP]: https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol
[Link 1]: https://en.wikipedia.org/wiki/Hypermedia
[Web]: https://en.wikipedia.org/wiki/World_Wide_Web
[URL]: https://en.wikipedia.org/wiki/URL
[JSON]: https://en.wikipedia.org/wiki/JSON
[XML]: https://en.wikipedia.org/wiki/XML
[Link 2]: https://en.wikipedia.org/wiki/HATEOAS
[Link 3]: https://twitter.com/fielding/status/1108092713516163072?lang=en
[RPC]: https://en.wikipedia.org/wiki/Remote_procedure_call
[https_roy.gbiv.com_untangled_2008_rest-apis-must-be-hypertext-driven_comment-724]: https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-724
[URI]: https://en.wikipedia.org/wiki/Uniform_Resource_Identifier
[https_roy.gbiv.com_untangled_2008_rest-apis-must-be-]: https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
[REST 2]: https://en.wikipedia.org/wiki/Representational_state_transfer#Architectural_constraints
[API]: https://en.wikipedia.org/wiki/Application_programming_interface
[Link 4]: http://www.crummy.com/
[Richardson]: https://martinfowler.com/articles/richardsonMaturityModel.html
[RESTful_-Richardson API]: /images/20230209/d1140811992b4de1a143c0f60ca7d1a9.png
[https_twitter.com_fielding_status_1125438763507654658]: https://twitter.com/fielding/status/1125438763507654658
[https_www.javacodegeeks.com_restful-services-with-hateoas-rest-the-refresher.html]: https://www.javacodegeeks.com/restful-services-with-hateoas-rest-the-refresher.html