RESTful API方法；HEAD和OPTIONS

Question

RESTful API方法；HEAD和OPTIONS

phphttprest

158

我正在使用PHP编写一个RESTful API模块，对于动词HEAD和OPTIONS有些混淆。

OPTIONS用于检索给定资源的可用HTTP动词？

HEAD用于确定给定资源是否可用？

如果有人能够澄清这些动词的含义，那将不胜感激。

注：澄清是针对RESTful API体系结构重新使用HTTP动词而言。我现在意识到，HEAD和OPTIONS都不应该被重新用途，而应该像任何HTTP应用程序一样以可预测的方式行事。时间过得真快啊。

- Dan Lugg

可能是因为HTTP规范在网络上很容易获取。 - Gordon

@Gordon - 好的，我理解RESTful API服务旨在利用现有的HTTP规范，但我认为在实现细节上可能会有一些偏差。我的错。 - Dan Lugg

23

大多数物品的规格可以在网上轻松获取。SO 上的问题是为了澄清文档以外的内容而存在的，这符合这种情况。 - Andrew Ensley

3个回答

86

根据：http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html 9.2 OPTIONS 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响应应包括任何头字段，指示服务器实现的可选功能并适用于该资源（例如，Allow），可能包括此规范未定义的扩展。如果有任何响应体，则还应包括有关通信选项的信息。这样的主体格式未由本规范定义，但可以由HTTP的未来扩展定义。内容协商可以用于选择适当的响应格式。如果不包括响应正文，则响应必须包括带有“0”的字段值的Content-Length字段。

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

9.4 HEAD

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

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

- sdolgy

1

感谢 @sdolgy 的全面报价；然而，在实践中，许多成功的 RESTful API 模块是否遵循这些 HTTP 标准？或者对于这些操作，是否有可接受的简化响应？这不是因为懒惰，而仅仅是出于好奇；我可能会实现必要的所有内容来保持一致。 - Dan Lugg

2

如果您正在构建自己的API，我认为您应该尽量遵循文档标准以使您的生活更轻松...以及使用您的API的人们的生活更轻松。不要跟随Microsoft。RFC是一个好的对齐标准。 - sdolgy

不确定这是否是预期的目的：“此规范保留方法名称CONNECT，用于代理可以动态切换为隧道（例如SSL隧道[44]）。”...在stackexchange.com网站上发布另一个问题可能会有所帮助... - sdolgy

感谢 @sdolgy。我知道那不是预期的用法，但是在这个应用程序中将不会使用该功能，并且它将是一种很好的动词，用于基于资源的身份验证。我会研究一下，并在必要时询问周围的人。非常感谢您的见解 :) - Dan Lugg

2

@DanLugg，你的应用程序可能没有以 SSL 隧道方式利用 CONNECT，但是想象一下，如果你的应用程序的消费者有一个代理实现了 RFC 中指定的 CONNECT 方式，那么请求可能无法传递到你的应用程序。 - Steve Buzonas

显示剩余4条评论

56

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

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

- Quentin

感谢@Quentin，我想到了“OPTIONS”，并且这样的实现对于我的现有方法来说非常容易。根据sdolgy的RFC引用，“OPTIONS”在格式方面没有定义任何标准。它是否假定响应格式与其他响应相同？（例如：JSON、XML等） - Dan Lugg

1

@Tomcat 引用 RFC 的话说：“内容协商可以用来选择适当的响应格式。”换句话说：响应应该是请求头所要求的。 - Gordon

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Yuriy Kvartsyanyy · Accepted Answer

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

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

服务器响应

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

标题

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方法，例如我们可以通过DELETE或PUT更新它吗？

HEAD：检查资源是否已更改。在维护缓存版本时非常有用。

HEAD：检索关于资源的元数据，例如其媒体类型或大小，在进行可能产生代价的检索之前先了解这些信息。

HEAD, OPTIONS：测试资源是否存在且可访问。例如，在应用程序中验证用户提交的链接。

这里是有关如何将HEAD和OPTIONS整合到RESTful架构中的简洁文章。