RESTful Web 服务 - 问题与解答
REST 代表表述性状态转移。
REST 是基于 Web 标准的架构，使用 HTTP 协议进行数据通信。它围绕资源展开，每个组件都是一个资源，并且资源通过 HTTP 标准方法由通用接口访问。REST 最初由 Roy Fielding 于 2000 年提出。
在 REST 架构中，REST 服务器仅提供对资源的访问，REST 客户端访问并呈现资源。这里每个资源都由 URI/全局 ID 标识。REST 使用各种表示形式来表示资源，如文本、JSON 和 XML。如今，JSON 是 Web 服务中最流行的格式。
以下是 REST 架构中常用的众所周知的 HTTP 方法 −
GET −提供对资源的只读访问权限。
PUT − 用于更新/替换新资源。
DELETE − 用于删除资源。
POST − 用于更新现有资源或创建新资源。
OPTIONS − 用于获取对资源的支持操作。
Web 服务是用于在应用程序或系统之间交换数据的开放协议和标准的集合。使用各种编程语言编写并在各种平台上运行的软件应用程序可以使用 Web 服务通过 Internet 等计算机网络交换数据，其方式类似于单台计算机上的进程间通信。
基于 REST 架构的 Web 服务称为 RESTful Web 服务。这些 Web 服务使用 HTTP 方法来实现 REST 架构的概念。RESTful Web 服务通常定义 URI(统一资源标识符)服务，提供资源表示(例如 JSON)和一组 HTTP 方法。
REST 架构将每个内容视为资源。这些资源可以是文本文件、html 页面、图像、视频或动态业务数据。REST 服务器仅提供对资源的访问，REST 客户端访问和修改资源。这里每个资源都由 URI/全局 ID 标识。
REST 使用各种表示形式来表示资源，其中文本、JSON、XML。XML 和 JSON 是资源最流行的表示形式。
以下是在 RESTful Web 服务中设计资源表示格式时需要考虑的重要事项 −
可理解性 − 服务器和客户端都应该能够理解和利用资源的表示格式。
完整性 −格式应该能够完整地表示资源。例如，一个资源可以包含另一个资源。格式应该能够表示简单和复杂的资源结构。
可链接性 − 一个资源可以链接到另一个资源，格式应该能够处理这种情况。
RESTful Web 服务使用 HTTP 协议作为客户端和服务器之间的通信媒介。
客户端以 HTTP 请求的形式发送消息，服务器以 HTTP 响应的形式响应。这种技术称为消息传递。这些消息包含消息数据和元数据，即有关消息本身的信息。
HTTP 请求有五个主要部分 −
动词 − 指示 HTTP 方法，例如 GET、POST、DELETE、PUT 等。
URI − 用于识别服务器上的资源的统一资源标识符 (URI)。
HTTP 版本 − 指示 HTTP 版本，例如 HTTP v1.1。
请求标头 − 包含 HTTP 请求消息的元数据作为键值对。例如，客户端(或浏览器)类型、客户端支持的格式、消息正文的格式、缓存设置等。
请求正文 − 消息内容或资源表示。
HTTP 响应有四个主要部分 −
状态/响应代码 − 指示所请求资源的服务器状态。例如，404 表示未找到资源，200 表示响应正常。
HTTP 版本 − 指示 HTTP 版本，例如 HTTP v1.1。
响应标头 −包含 HTTP 响应消息的元数据(键值对)。例如，内容长度、内容类型、响应日期、服务器类型等。
响应主体 − 响应消息内容或资源表示。
寻址是指定位服务器上的一个或多个资源。它类似于定位一个人的邮政地址。
URI 代表统一资源标识符。 REST 架构中的每个资源都由其 URI 标识。
URI 的用途是定位托管 Web 服务的服务器上的资源。
URI 的格式如下 −
<protocol>://<service-name>/<ResourceType>/<ResourceID>
VERB 标识要对资源执行的操作。
以下是在设计 URI 时需要考虑的重要事项 −
使用复数名词 − 使用复数名词定义资源。例如，我们使用用户来标识用户为资源。
避免使用空格 −使用长资源名称时，请使用下划线 (_) 或连字符 (-)，例如，使用 authorized_users 而不是 authorized%20users。
使用小写字母 − 尽管 URI 不区分大小写，但最好只使用小写字母来保留 url。
保持向后兼容性 − 由于 Web 服务是公共服务，因此一旦公开的 URI 应始终可用。如果 URI 更新，请使用 HTTP 状态代码 300 将旧 URI 重定向到新 URI。
使用 HTTP 动词 − 始终使用 HTTP 动词(如 GET、PUT 和 DELETE)对资源执行操作。在 URI 中使用操作名称并不好。
根据 REST 架构，RESTful Web 服务不应在服务器上保留客户端状态。此限制称为无状态性。客户端有责任将其上下文传递给服务器，然后服务器可以存储此上下文以处理客户端的进一步请求。例如，服务器维护的会话由客户端传递的会话标识符标识。
以下是 RESTful Web 服务中无状态的好处 −
Web 服务可以独立处理每个方法请求。
Web 服务不需要维护客户端以前的交互。它简化了应用程序设计。
由于 HTTP 本身是一种无状态协议，因此 RESTful Web 服务可以与 HTTP 协议无缝协作。
以下是 RESTful Web 服务中无状态的缺点 −
Web 服务需要在每个请求中获取额外信息，然后进行解释以获取客户端的状态，以防需要处理客户端交互。
幂等操作意味着无论调用这些操作多少次，其结果始终相同。
PUT 和 DELETE 操作是幂等的。
GET 操作是只读的，并且安全。
PUT 和 POST 操作几乎相同，区别仅在于结果，PUT 操作是幂等的，而 POST 操作会导致不同的结果。
它应该列出 Web 服务中支持的操作，并且应该是只读的。
它应该只返回 HTTP Header，没有 Body，并且应该是只读的仅。
缓存是指将服务器响应存储在客户端本身中，以便客户端无需一次又一次地向服务器请求相同的资源。服务器响应应该包含有关如何进行缓存的信息，以便客户端在一段时间内缓存响应或从不缓存服务器响应。
Date 标头提供资源的创建日期和时间。
Last Modified 标头提供资源的上次修改日期和时间。
Cache-Control 是控制缓存的主要标头。
Expires 标头设置缓存的到期日期和时间。
公共指令表示资源可由任何组件缓存。
私有指令表示资源只能由客户端和服务器缓存，没有中介可以缓存资源。
no-cache/no-store 指令指示资源不可缓存。
max-age 指令指示缓存有效期为 max-age 秒。此后，客户端必须发出另一个请求。
如果已超过 max-age，must-revalidate 指令会指示服务器重新验证资源。
始终保持静态内容(如图像、css、JavaScript)可缓存，有效期为 2 到 3 天。 切勿将有效期设置得太高。
动态内容应仅缓存几个小时。由于 RESTful Web 服务使用 HTTP URL 路径，因此以与网站相同的方式保护 RESTful Web 服务非常重要。以下是在设计 RESTful Web 服务时应遵循的最佳实践 −
验证 − 验证服务器上的所有输入。保护您的服务器免受 SQL 或 NoSQL 注入攻击。
基于会话的身份验证 − 每当向 Web 服务方法发出请求时，使用基于会话的身份验证对用户进行身份验证。
URL 中没有敏感数据 −切勿在 URL 中使用用户名、密码或会话令牌，这些值应通过 POST 方法传递给 Web 服务。
方法执行限制 − 允许限制使用 GET、POST、DELETE 等方法。GET 方法不应能够删除数据。
验证格式错误的 XML/JSON − 检查传递给 Web 服务方法的输入是否格式正确。
抛出通用错误消息 − Web 服务方法应使用 HTTP 错误消息(如 403)来显示访问被禁止等。
HTTP 状态代码是标准代码，指的是服务器上完成的任务的预定义状态。例如，HTTP 状态 404 表示请求的资源不在服务器上。
这意味着，OK，显示成功。
当使用 POST 或 PUT 请求成功创建资源时，这意味着，CREATED。使用位置标头返回指向新创建的资源的链接。
当响应主体为空时，它表示无内容，例如 DELETE 请求。
它表示未修改，用于在有条件 GET 请求的情况下减少网络带宽使用。响应主体应为空。标头应包含日期、位置等。
这意味着，BAD REQUEST，表示提供了无效的输入，例如验证错误，缺少数据。
这意味着，FORBIDDEN，表示用户无权访问正在使用的方法，例如，在没有管理员权限的情况下删除访问权限。
这意味着，NOT FOUND，表示该方法不可用。
这意味着，CONFLICT，表示执行方法时发生冲突的情况，例如，添加重复条目。
这意味着，内部服务器错误，表示服务器在执行该方法时抛出了某些异常。
JAX-RS 代表 RESTful Web 服务的 JAVA API。JAX-RS 是一种基于 JAVA 的编程语言 API 和规范，用于为创建的 RESTful Web 服务提供支持。其 2.0 版本于 2013 年 5 月 24 日发布。JAX-RS 大量使用 Java SE 5 提供的注释来简化基于 JAVA 的 Web 服务创建和部署的开发。它还为创建 RESTful Web 服务的客户端提供支持。
