做伊瑞尔竞技场的网站,深圳网站建设最专业的,wordpress 视差,旅游搭建网站restful rest在这篇文章中#xff0c;我们将介绍有关HATEOAS的RESTful服务的综合文章。 REST#xff1a;刷新器。 1.简介 “不好了#xff01; 请#xff0c;不要再发表有关REST的文章#xff01;” 你们中的许多人可能会尖叫#xff0c;这是正确的。 已经出版了太多的… restful rest 在这篇文章中我们将介绍有关HATEOAS的RESTful服务的综合文章。 REST刷新器。 1.简介 “不好了 请不要再发表有关REST的文章” 你们中的许多人可能会尖叫这是正确的。 已经出版了太多的教程帖子讨论和最佳实践而再提出一个几乎没有任何意义。 坦白地说对REST的理解因人而异。 并非每个人都有时间也有愿望阅读Roy Fielding优秀论文的“ 代表性状态转移”REST一章因此对于许多REST而言 无论其含义如何它基本上都是基于HTTP的API的代名词。 但是 REST的一面大部分时间都处于黑暗中毫无根据地被遗忘和忽略 超媒体 。 目录 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为架构师和系统设计了一套原则和约束但这绝不是实现。 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?langzh-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视为宗教而是要证明每个元素都很重要而且存在是有原因的。 5.理查森成熟度模型 REST保护下的Web服务和API的碎片要求采取行动。 作为响应 伦纳德·理查森 Leonard Richardson开发了API成熟度模型通常简称为Richardson成熟度模型 该模型实质上定义了4个级别的API成熟度。 理查森API成熟度模型 这个非常简单的模型有助于轻松地确定特定Web API在实现RESTful方面所处的位置请注意每个级别都基于其下一个级别。 您可能还会注意到该模型并非普遍适用而是明确关注基于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原则此级别的Web API使用HTTP谓词语义来区分各个资源上的不同动作。 这是大多数现代Web API最终达到的级别声称“足够好”。 3级–超媒体控件 在最顶层我们遇到了使用HATEOAS和超媒体控件来引导客户端/服务器交互的Web API。 在此级别上API可以称为真正的RESTful 。 有了这个成熟度模型每当您听到“……在我们组织中我们构建暴露REST Web API的应用程序……”时我们很可能在谈论Level 2 。 6. RESTful服务–结论 在本教程的介绍性部分中我们更新了对REST体系结构样式的了解尤其是重新介绍了其强制性原则和约束。 我们还揭开了RESTful一词的起源以及它如何应用于现代Web API和服务的神秘感。 再一次 罗伊·菲尔丁 Roy Fielding将其牢牢地钉牢了。 通过包含超文本的自描述消息的统一接口提供基于网络的资源访问的API该消息包含超文本以指示潜在的状态转换它可能是RESTful应用程序的整个系统的一部分 https://twitter.com/fielding/status/1125438763507654658 在本教程的后续部分中我们将大部分时间花在谈论HATEOAS上 这可能是所有声称被称为真正的RESTful的 API中最困难但也是功能最强大的元素。 7.接下来 在本教程的下一部分中我们将开始讨论使用HATEOAS功能丰富您的Web服务和API的多种方法。 翻译自: https://www.javacodegeeks.com/restful-services-with-hateoas-rest-the-refresher.htmlrestful rest
