RESTful API 方法；头部和选项

Question

我正在用 PHP 为一个应用程序编写一个 RESTful API 模块，我对动词 HEAD 和 OPTIONS 有点混淆。

• OPTIONS  用于检索给定资源的可用 HTTP 动词？
• HEAD 用于判断给定资源是否可用？

如果有人能澄清*这些动词，那将不胜感激。

_{* 说明是关于重新利用 HTTP 动词的 RESTful API 架构。从那以后，我意识到HEAD 和OPTIONS 都应该不被重新使用，而是像任何HTTP 应用程序一样表现出可预测的行为。哦，我们如何在 2 年内成长。}

Answer 1

OPTIONS 方法返回有关 API 的信息（方法/内容类型）

HEAD 方法返回关于资源（版本/长度/类型）的信息

服务器响应

选项

HTTP/1.1 200 OK
Allow: GET,HEAD,POST,OPTIONS,TRACE
Content-Type: text/html; charset=UTF-8
Date: Wed, 08 May 2013 10:24:43 GMT
Content-Length: 0

头部

HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Type: text/html; charset=UTF-8
Date: Wed, 08 May 2013 10:12:29 GMT
ETag: "780602-4f6-4db31b2978ec0"
Last-Modified: Thu, 25 Apr 2013 16:13:23 GMT
Content-Length: 1270

• OPTIONS 识别资源支持的 HTTP 方法，例如我们可以通过 PUT 删除或更新它吗？
• HEAD 检查资源是否已更改。这在维护资源的缓存版本时很有用
• HEAD 检索有关资源的元数据，例如在进行可能昂贵的检索之前，它的媒体类型或大小
• HEAD, OPTIONS 测试资源是否存在且是否可访问。例如，在应用程序中验证用户提交的链接

Here 是一篇关于 HEAD 和 OPTIONS 如何融入 RESTful 架构的简洁明了的文章。

Answer 2

根据：http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

9.2 选项

OPTIONS 方法表示请求有关在由 Request-URI 标识的请求/响应链上可用的通信选项的信息。此方法允许客户端确定与资源相关的选项和/或要求，或服务器的功能，而无需暗示资源操作或启动资源检索。

对此方法的响应不可缓存。

如果 OPTIONS 请求包括一个实体主体（如 Content-Length 或 Transfer-Encoding 的存在所示），则媒体类型必须由 Content-Type 字段指示。尽管本规范没有定义这种主体的任何用途，但 HTTP 的未来扩展可能会使用 OPTIONS 主体在服务器上进行更详细的查询。不支持此类扩展的服务器可能会丢弃请求正文。

如果 Request-URI 是星号（“*”），则 OPTIONS 请求通常适用于服务器而不是特定资源。由于服务器的通信选项通常取决于资源，因此“*”请求仅用作“ping”或“no-op”类型的方法；除了允许客户端测试服务器的功能之外，它什么也不做。例如，这可用于测试代理的 HTTP/1.1 合规性（或不合规性）。

如果 Request-URI 不是星号，则 OPTIONS 请求仅适用于与该资源通信时可用的选项。

200 响应应该包含任何标头字段，这些字段指示服务器实现的并适用于该资源的可选功能（例如，允许），可能包括本规范未定义的扩展。响应正文（如果有）还应包括有关通信选项的信息。本规范未定义此类主体的格式，但可能由 HTTP 的未来扩展定义。内容协商可用于选择适当的响应格式。如果未包含响应正文，则响应必须包含字段值为“0”的 Content-Length 字段。

Max-Forwards 请求头字段可用于定位请求链中的特定代理。当代理在一个absoluteURI 上接收到一个允许转发请求的OPTIONS 请求时，代理必须检查Max-Forwards 字段。如果 Max-Forwards 字段值为零（“0”），则代理不得转发消息；相反，代理应该使用自己的通信选项进行响应。如果 Max-Forwards 字段值是大于零的整数，则代理在转发请求时必须减少字段值。如果请求中不存在 Max-Forwards 字段，则转发的请求不得包含 Max-Forwards 字段。

9.4 头部

HEAD 方法与 GET 相同，只是服务器不得在响应中返回消息体。响应 HEAD 请求的 HTTP 标头中包含的元信息应该与响应 GET 请求发送的信息相同。此方法可用于获取有关请求所隐含的实体的元信息，而无需传输实体主体本身。这种方法通常用于测试超文本链接的有效性、可访问性和最近的修改。

对 HEAD 请求的响应可能是可缓存的，因为响应中包含的信息可以用于从该资源更新先前缓存的实体。如果新字段值表明缓存的实体与当前实体不同（如 Content-Length、Content-MD5、ETag 或 Last-Modified 的变化所表明的那样），则缓存必须将缓存条目视为陈旧的。

Answer 3

OPTIONS 告诉您诸如“此资源允许使用哪些方法”之类的信息。

HEAD 获取您发出 GET 请求时将获得的 HTTP 标头，但没有正文。这让客户端可以确定缓存信息、返回什么内容类型、返回什么状态码。可用性只是其中的一小部分。