RESTful 架构基础( 四 ) _小知识

还有另外三个没有广泛使用但是有价值的动词。
4.5 HEAD
HEAD 动词用来请求资源，但不实际检索。客户端可以通过 HEAD 检查资源是否存在，并检查资源相关的元数据。
4.6 OPTIONS
OPTIONS 动词也可以用来查询服务器相关资源的情况，方法是询问哪些其它动词可用于该资源。
4.7 PATCH
最新的动词 PATCH 直到2010年才正式采纳为 HTTP 的一部分。旨在提供一种标准化方式来表示部分更新。PATCH 请求通过标准格式让交互的意图更明确。这是推荐使用 PATCH 而非 POST 的原因，尽管 POST 可以用于任何事情。IETF 发布了 RFC 文档，定义用于 PATCH 操作的 XML 和 JSON 。
如果客户端 PATCH 请求的 header 中带 If-Match，则此部分为幂等更新。可以重试中断的请求，因为如果第一次请求成功，那么 If-Match header 会不同于新状态。如果相同，则未处理原始请求可应用 PATCH 。
5. 响应码
HTTP 响应码为我们在客户端和服务器之间的对话提供了丰富的请求状态信息。大多数人只熟悉一般意义上的200、403、404或者500，但是还有更多有用的代码可供使用。这里表格并不全面，但是它们涵盖了许多在 RESTful 环境中应该考虑使用的最重要代码。数字可按照以下类别分组：

1XX：信息类
2XX：操作成功
3XX：重定向
4XX：客户端错误
5XX：服务器错误

第一组响应码表明客户端的请求格式正确且处理成功。具体操作如下表所示：

文章插图

表1 成功的客户端请求

文章插图

表2 — 客户端重定向请求
表3中的响应代码表示客户端请求无效，如果条件不发生变化，重新请求仍无法处理。这些故障可能有请求格式错误、未授权的请求、请求的资源不存在等。

文章插图

表3 客户端请求错误

最后，表4中的响应代码表示服务器暂时无法处理客户端请求（可能仍然无效）。客户端应当在将来的某个时候重新请求。

文章插图

表4 服务器处理请求错误

服务根据其自身功能要求具有不同程度的可扩展性。
注意：试试响应代码418，它会返回简洁有力的回复："我是一个茶壶。"
5.1 REST 资源
5.1.1 论文
Fielding 博士的论文《架构的风格与基于网络的软件架构设计》是对 RESTful 思想的主要介绍：http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
5.1.2 RFC 规范
REST 常见用法的技术规范由**国际互联网工程任务组（IETF）定义，按照请求评议（RFC）**流程完善。规范由数字定义，并随着时间推移不时更新版本，以替换已经过时的文件。目前，这里有最新的相关 RFC 文件。
5.1.2.1 URI
RFC 3986定义了 URI 命名方案的通用语法。URI 是一种命名方案，包含了对其他如网址、支持名字子空间等编码方案。网址：http://www.ietf.org/rfc/rfc3986.txt>
5.1.2.2 URL
Url 是 URI 的一种形式，其中嵌入了充足的信息（通常是访问方案和地址），用于解析和定位资源统一资源定位符。网址：http://www.ietf.org/rfc/rfc1738.txt
5.1.2.3 IRI
国际化资源标识符（IRI）在概念上是一个用 Unicode 编码的 URI，用于在 Web 上使用的标识符中支持世界上各种语言的字符。IETF 选择创建一个新的标准，而不是改变 URI 方案本身，以避免破坏现有的系统并明确区分这两种方法。那些支持 IRI 的人故意这样做。还定义了在 IRI 和 URI 之间进行转换的映射方案。网址<：http://www.ietf.org/rfc/rfc3987.txt
5.1.2.4 HTTP
HTTP 1.1版本定义了一个应用程序协议，用于操作通常以超媒体格式表示的信息资源。虽然它是一个应用级协议，但通常不与应用程序绑定，由此产生了重要的体系结构优势。大多数人认为 HTTP 和超文本标记语言文（HTML）就是“Web”，但是 HTTP 在非面向文档的系统开发中也很有用。网址：http://www.ietf.org/rfc/rfc2616.txt
5.1.2.5 PATCH 格式
JAVAScript 对象表示法（JSON）Patch 网址：https://www.ietf.org/rfc/rfc6902.txt
XML Patch 网址：https://www.ietf.org/rfc/rfc7351.txt
5.2 描述语言