英语原文共 21 页，剩余内容已隐藏，支付完成后下载完整资料
第二章
基于rest的Web服务：原则，模式，新兴技术
作者：Cesare Pautasso
摘要 RESTful Web服务是在Web上发布的软件服务，充分利用并正确使用HTTP协议。本章介绍REST架构风格，以及如何使用它来设计Web服务API。我们总结了REST架构风格的主要设计约束，并讨论它们如何影响所谓的RESTful Web服务API的设计。我们举例说明如何将Web看作是一种新型的软件连接器，它能够协调分布式，有状态和自主的软件服务。我们总结了一章，一个关键概述一组新兴技术，可用于支持RESTful Web服务的开发和操作。
2.1 引言
REST即表述性状态传递[13]。该框架解释了万维网的质量属性，被看作是一个开放，分布式和分散的超媒体应用程序，从1990年的几个网页扩展到数十亿可寻址的网络资源[4,6]。即使将Web体系结构的全局快照（被视为一组大量的Web浏览器，Web服务器及其集合状态）不再实用，仍然可以描述此类Web体系结构遵循的风格。 REST架构风格包括定义HTTP协议[12]的设计约束，基本标准连同URI和HTML，已经启用了Web [5]。这些约束构成了REST架构风格，并在他的博士论文中由Roy Fielding提炼[11]。
在过去十年中，Web已经从用于发布和发现文档（即，网页）的大规模超媒体应用程序发展成用于共享数据和访问作为服务递送的远程软件组件的可编程介质。随着Web的普及，TCP / IP端口80默认在大多数互联网上被开放，使得可以使用HTTP协议[12]（默认情况下在端口80上运行）作为隧道消息的通用手段 在业务到业务集成场景中。RESTful Web服务 - 而不是纯（或大[22]）Web服务 - 强调正确和完整地使用HTTP协议在Web上发布软件系统[24]。Web上发布的更多服务声称 使用REST进行设计。当我们要讨论时，即使所有都使用HTTP协议本身，并不是所有的人都完全遵守REST架构风格的约束[16]。
在本章中，我们将介绍如何将Web看作是一种新型的软件连接器，它能够协调分布式，有状态和自主的软件服务。我们总结了REST架构风格的主要设计约束，并讨论它们如何影响所谓的RESTful Web服务API的设计。
2.2原理
了解万维网下的架构原则可以改进其他分布式系统的设计，例如集成企业架构。这是RESTful Web服务的声明，它是根据REST架构风格[11]设计的，它强调组件交互的可扩展性，促进组件接口的重用和通用性，减少组件之间的耦合，并利用中间组件来减少交互延迟 ，实施安全性，并封装遗留系统。
2.2.1设计约束
REST架构风格的主要设计约束是：通过资源标识的全局可寻址性，所有资源共享的统一接口，服务之间的无状态交互，自描述消息和超媒体作为通过引用分散资源发现的机制。
- 可寻址性由一个Web服务发布的所有资源应该被赋予一个唯一和稳定的标识符[17]。这些标识符在全球范围内是有意义的，所以没有中央权威参与制造它们，它们可以独立于任何上下文被解引用。 资源的概念保持非常一般性。
- 统一接口所有资源通过统一接口进行交互，这提供了一个小的，通用的和功能上充分的方法集，以支持服务之间的所有可能的交互。 每个方法在其对资源状态的影响方面具有良好定义的语义。 在Web及其HTTP协议的上下文中，统一接口包括可以应用于所有Web资源标识符的方法（例如，GET，PUT，DELETE，POST，HEAD，OPTIONS等） 到HTTP方案）。 如果需要，可以扩展该组方法（例如，PATCH最近被提议作为处理部分资源更新的添加[8]），并且基于诸如WebDAV的HTTP的其他协议包括附加的方法[14]。
- 无状态交互服务不在它们之间建立任何永久会话，跨越多个交互。这确保对资源的请求是彼此独立的。 在每次交互结束时，没有在客户端和服务器之间保留的共享状态。 请求可能导致资源的状态更改，其新状态对其所有客户端立即可见。
- 自描述消息服务通过交换请求和响应消息来交互，其包含数据（或资源的表示）和对应的元数据。表述可以根据客户背景，兴趣和能力而变化。例如，移动客户端可以检索资源的低带宽表示。 同样，Web浏览器可以根据其用户偏好请求特定语言的网页的表示。这大大增强了REST架构的内在互操作性的程度，因为客户端可以与资源动态地协商最适当的表示格式（也称为媒体类型），而不是迫使所有客户端和所有资源使用相同的格式。请求和 响应消息还应该包含关于表示的显式元数据，使得服务不需要假设关于如何解析，处理和理解表示的任何种类的带外协议。
- 超媒体资源可能彼此相关。高级媒体是关于在资源表示中或相应的元数据中嵌入对相关资源的引用。因此，当处理表示时，客户端可以发现相关资源的标识符（或者更高的链接），并且当他们浏览由资源之间的关系构建的图时选择跟随链接。超媒体有助于处理分散式资源发现，也用于动态发现和描述服务之间的交互协议。尽管它的有用性，它也是在大多数Web服务API声称是RESTful中最少使用的约束。 因此，有时也遵循这个约束的Web服务API也被称为“超媒体API”[3]。
2.2.2成熟度模型
REST架构风格的主要设计约束也可以逐步采用，导致由Leonard Richardson提出的RESTful Web服务的安全模型定义。 这导致讨论是否只有完全成熟的服务才可以称为RESTful。 然而，在实践的状态下，许多在较低成熟度级别中被分类的服务已经表现为使用REST。
- 级别0：HTTP作为隧道这些都是通过HTTP POST请求和响应简单地交换XML文档（有时称为普通旧XML文档，而不是SOAP消息）的服务，有效地遵循某些XML-RPC协议[28]。类似的方法之后是以JSON，YAML或用于串行化远程过程调用的输入和输出参数的其他格式替换XML有效载荷的服务，该远程过程调用恰好通过开放的HTTP端点被隧道传输。即使这样的服务没有使用SOAP消息，它们也没有真正充分利用HTTP协议根据REST约束。特别地，由于所有消息到达相同的端点URL，服务只能通过从XML（或JSON）有效载荷中解析这样的信息来区分不同的操作。
- 级别1：资源与使用单个端点通过HTTP协议隧道化RPC消息相反，成熟度级别1上的服务使用多个标识符来区分不同的资源。每个交互被寻址到特定资源，然而这仍然可能被误用以识别要对有效载荷执行的不同操作或方法，或识别给定类的对象的不同实例，请求有效载荷被寻址到该对象的不同实例。
- 级别2：HTTP动词除了细粒度资源识别之外，成熟度级别2的服务还可以正确使用REST统一接口，特别是HTTP动词。这意味着，不仅客户端可以对资源执行GET，DELETE，PUT，而且还可以对其进行POST，但是也遵循此类方法的语义。例如，服务设计者确保对他们的服务的GET，PUT和DELETE请求是幂等的。由于我们可以假设HTTP方法根据其标准语义使用，我们可以使用相应的安全和幂等性属性通过引入中介来优化系统。例如，安全和副作用的自由GET请求的结果可以被缓存，失败的PUT和DELETE请求可以自动重试。另外，服务正确地使用HTTP状态代码，例如指示方法是否适用于给定资源或指派在哪一方负责失败的交互之间的责任。
- 级别3：超媒体这些是完全成熟的RESTful Web服务，它除了暴露共享同一个统一接口的多个可寻址资源之外，还利用超媒体来建模资源之间的关系。 这是通过在资源表示中嵌入所谓的超媒体控制来实现的[19]。根据所选的媒体类型，超媒体控制例如链接或表单可以由客户端解析，识别和解释以驱动其在相关资源的图内的导航。超媒体控件将根据关系的语义来键入，并包含客户端对相关资源制定请求所需的所有信息。 与预先知道将要使用的资源的所有地址相反，客户端因此可以通过跟随特定类型的链接来动态地发现应当与哪个资源交互。 实现这种成熟水平的关键是支持超媒体控制的媒体类型的选择（例如，XML或JSON不支持，而ATOM，XHTML或JSON-LD支持）。服务根据资源的当前状态改变给予客户端的链接集合的能力也是丑陋的HATEOAS（作为应用状态引擎的超文本）首字母缩略词的已知，现在更简单的“超媒体 “术语是优选的[23]。服务的成熟度级别还影响嵌入服务的体系结构的质量属性。通过打开的HTTP端口（级别0）隧道化消息只导致通信和交换数据的基本能力，但是安全问题很可能导致脆弱的集成系统，这是很难演变和衡量。区分多个资源有助于将分割和征服技术应用于服务接口的设计，并使服务能够使用全局标识符来寻址每个正在发布的资源。对每个资源应用标准化和统一的接口消除了不必要的变化（因为只有少数普遍接受的方法适用于资源）并且使所有服务能够与架构内的所有资源进行交互，从而促进互操作性和偶然的重用[29]。另外，组成统一接口的方法的语义可以被调整，使得架构的可扩展性和可靠性被增强。然而，只有超媒体提供的资源的动态可发现性有助于最小化所得到的架构内的耦合。
2.2.3比较REST与WS- *
成熟度模型也可以用于对RESTful Web服务和WS- * Web服务（图2.1）进行粗略比较。 更详细的比较可以在[22]中找到。随着成熟度增加，服务将从使用单个通信端点切换到许多URI（在资源标识轴上）。 类似地，可能的方法（或操作）将限于统一接口的方法，而不是使用WSDL文档中明确描述的自己的一组操作来设计每个服务。从REST透视图，所有WSDL操作都通过单个HTTP 动词（POST），从而降低被视为应用协议的HTTP的表现力，其被用作用于隧道化消息的传输协议。在WSDL中，几个通信端点可以与相同的服务相关联，尽管这些端点不是用于区分HTTP资源，而是可以用于通过替代通信机制来访问相同的服务。
图2.1 设计图：RESTful Web服务与WS- * Web服务
第三个轴在成熟度模型中不直接反映，但对于理解两个技术栈之间的差异也很重要，其中一个具有SOAP协议和XML格式的基础，而另一个则开放选择哪个消息格式 （在表示轴上示出），使得客户端和服务可以协商最合适的格式以实现互操作性。
2.3例子
作为这个例子的灵感，我们使用了Doodle RESTAPI，它提供了对（http://www.doodle.ch）的Doodle poll Web服务的编程访问。 Doodle是一个非常受欢迎的服务，它允许最小化交换的电子邮件的数量，以找到一组人之间的协议。服务允许通过配置一组选项（这可以是一组日期调度 会议，但也可以是一组任意字符串）。然后，将轮询的链接邮寄给参与者，通过选择首选选项邀请他们回答投票。 轮询的当前状态可以由发起者在任何时间轮询，发起者通常通过第二电子邮件消息通知结果的参与者。
简单Doodle REST API（图2.2）发布两种资源：投票（一组选项一次可以选择）和投票（在给定投票中的人的选择）。 在这两种资源之间存在一种自然的包含关系，这自然地适用于在URI中使用/作为路径分隔符的约定。因此，服务发布/poll根资源，其包含一组/poll/{id}轮询实例，其包括相应的投票集合/poll/{id}/vote/{id}。
图2.2 简单的Doodle REST API
2.3.1列出激活的投票
根/poll资源用于检索（使用GET）到实例化的轮询的链接列表：
2.3.2创建新的投票
相同的/ poll资源作为工厂资源，接受POST请求以创建新的轮询实例。 新创建的轮询的标识符作为与位置响应头相关联的链接返回。
除了由客户端提供的选项集之外，新创建的轮询资源的表示还包含到用于投票的资源的链接。 客户可以通过链接来表达自己的意见并作出选择。 嵌套投票资源作为个人投票的工厂资源。
2.3.4铸造投票
在处理上一个请求之后，已经进行了新的投票，并且投票的状态已经改变。获取现在将返回不同的表示，其包括关于投票的信息。
rArr;GET /poll/201205012
Accept: application/xml
2.3.5更改投票
由于每个投票都有自己的URI，因此也可以使用PUT和DELETE来操纵它的状态。 例如，客户端可能想要撤消投票（使用DELETE）或修改选项（使用PUT），如以下示例所示。
2.3.6与投票交互
通常，资源不一定可能响应使用统一接口的所有可能方法的请求。在简单涂鸦REST API的上下文中，如图2.2所示，已经选择了不支持在/poll和/poll/{id}/vote资源上的PUT和DELETE。此外，不支持对个别实例/ poll/{id}或/poll/{id}/vote/{id}的POST请求。这些请求对资源的状态没有有意义的影响，因此不允许。尝试发出它们的客户端将收到错误的响应：
客户端还可以在使用OPTIONS方法的资源上尝试对它们执行之前询问哪些方法是允许的，如下所述:
OPTIONS请求将返回当前适用于响应Allow头中的资源的方法的列表。 所允许的方法的集合可以根据资源的状态而改变。
2.3.7删除投票
一旦投票收到足够的投票并做出决定，其状态将由服务无限期地保持，直到客户作出明确的删除请求为止。
后续针对删除轮询实例的请求也会收到错误的响应。
2.4模式
一旦建立了RESTful Web服务设计的基本架构原则，有时很难将其直接应用于特定Web服务API的设计。在本节中，我们收集少量的设计模式，为如何处理资源创建，长时间运行操作和并发更新提供一些指导。 其他已知模式解决了事件通知的特性，
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[137069]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
