RESTful API 方法;HEAD & OPTIONS

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测试资源是否存在且可访问。例如，验证应用程序中用户提交的链接

这是一篇关于HEAD和OPTIONS如何适应RESTful架构的漂亮而简洁的文章。

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

9.2 选项

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

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

如果 OPTIONS 请求包括实体正文（如内容长度或传输编码的存在所指示），则媒体类型必须由“内容类型”字段指示。尽管此规范未定义此类主体的任何用途，但 HTTP 的未来扩展可能会使用 OPTIONS 主体在服务器上进行更详细的查询。不支持此类扩展的服务器可能会丢弃请求正文。

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

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

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

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

9.4 头

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

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