php RESTful API 方法；头和选项

RESTful API methods; HEAD & OPTIONS

提问by Dan Lugg

I'm writing a RESTful API module for an application in PHP, and I'm a bit mixed on the verbs HEADand OPTIONS.

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

• OPTIONS?Used to retrieve the available HTTP verbs for a given resource?
• HEADUsed to determine whether a given resource is available?

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

If someone could clarify* these verbs, that would be much appreciated.

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

_{* The clarification was with respect to RESTful API architectures re-purposing HTTP verbs. I've since come to the realization that both HEADand OPTIONSshould notbe re-purposed, and instead behave predictably as any HTTP application should. Oh, how we grow in 2 years.}

_{* 澄清是关于重新利用 HTTP 动词的 RESTful API 架构。我既然来实现这两个HEAD和OPTIONS应该不会被重新定意，而是可预测的行为作为任何HTTP应用程序应该。哦，我们如何在 2 年内成长。}

采纳答案by sdolgy

As per: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

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

9.2 OPTIONS

The OPTIONS method represents a request for information about the communication options available on the request/response chain identified by the Request-URI. This method allows the client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval.

Responses to this method are not cacheable.

If the OPTIONS request includes an entity-body (as indicated by the presence of Content-Length or Transfer-Encoding), then the media type MUST be indicated by a Content-Type field. Although this specification does not define any use for such a body, future extensions to HTTP might use the OPTIONS body to make more detailed queries on the server. A server that does not support such an extension MAY discard the request body.

If the Request-URI is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to a specific resource. Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op" type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be used to test a proxy for HTTP/1.1 compliance (or lack thereof).

If the Request-URI is not an asterisk, the OPTIONS request applies only to the options that are available when communicating with that resource.

A 200 response SHOULD include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g., Allow), possibly including extensions not defined by this specification. The response body, if any, SHOULD also include information about the communication options. The format for such a body is not defined by this specification, but might be defined by future extensions to HTTP. Content negotiation MAY be used to select the appropriate response format. If no response body is included, the response MUST include a Content-Length field with a field-value of "0".

The Max-Forwards request-header field MAY be used to target a specific proxy in the request chain. When a proxy receives an OPTIONS request on an absoluteURI for which request forwarding is permitted, the proxy MUST check for a Max-Forwards field. If the Max-Forwards field-value is zero ("0"), the proxy MUST NOT forward the message; instead, the proxy SHOULD respond with its own communication options. If the Max-Forwards field-value is an integer greater than zero, the proxy MUST decrement the field-value when it forwards the request. If no Max-Forwards field is present in the request, then the forwarded request MUST NOT include a Max-Forwards field.

9.4 HEAD

The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. The metainformation contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request. This method can be used for obtaining metainformation about the entity implied by the request without transferring the entity-body itself. This method is often used for testing hypertext links for validity, accessibility, and recent modification.

The response to a HEAD request MAY be cacheable in the sense that the information contained in the response MAY be used to update a previously cached entity from that resource. If the new field values indicate that the cached entity differs from the current entity (as would be indicated by a change in Content-Length, Content-MD5, ETag or Last-Modified), then the cache MUST treat the cache entry as stale.

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

9.4 头部

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

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

回答by Yuriy Kvartsyanyy

OPTIONSmethod returns info about API(methods/content type)

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

HEADmethod returns info about resource(version/length/type)

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

Server response

服务器响应

OPTIONS

选项

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

HEAD

头

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

• OPTIONSIdentifying which HTTP methods a resource supports, e.g. can we DELETE it or update it via a PUT?
• HEADChecking whether a resource has changed. This is useful when maintaining a cached version of a resource
• HEADRetrieving metadata about the resource, e.g. its media type or its size, before making a possibly costly retrieval
• HEAD, OPTIONSTesting whether a resource exists and is accessible. For example, validating user-submitted links in an application

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

Hereis nice and concise article about how HEAD and OPTIONS fit into RESTful architecture.

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

回答by Quentin

OPTIONS tells you things such as "What methods are allowed for this resource".

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

HEAD gets the HTTP header you would get if you made a GET request, but without the body. This lets the client determine caching information, what content-type would be returned, what status code would be returned. The availability is only a small part of it.

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