RESTful API方法;头和选项


92

我正在为PHP中的应用程序编写RESTful API模块,并且动词HEAD和混合使用OPTIONS

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

如果有人能弄清楚这些动词,那将不胜感激。

*澄清是关于重新使用HTTP动词的RESTful API架构。我既然来实现这两个HEADOPTIONS应该不会被重新定意,而是可预测的行为作为任何HTTP应用程序应该。哦,我们两年内的成长。


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

@Gordon-足够公平,尽管我了解RESTful API服务旨在利用现有的HTTP规范,但我想我还是对实现细节有些偏颇。我的错。
丹·拉格

14
几乎所有规格都可以在网上找到。有关SO的问题需要在文档之外进行澄清。这很适合。
Andrew Ensley 2012年

Answers:


60

按照: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字段。如果最大转发字段值为零(“ 0”),则代理不得转发该消息;相反,代理应该使用自己的通信选项进行响应。如果Max-Forwards字段值是一个大于零的整数,则代理在转发请求时务必减少该字段值。如果请求中不存在Max-Forwards字段,则转发的请求不得包含Max-Forwards字段。

9.4头

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

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


1
感谢@sdolgy的全面报价;然而,在实践中就(应该)许多成功的RESTful API模块,坚持所有这些HTTP标准,或者是有一个可以接受的纤薄对这些操作的响应?不是出于懒惰,而是出于好奇;我可能会实施所有必要的坚持措施。
丹·拉格

2
如果您要构建自己的应用程序(我想是的话),则应尝试与记录的标准保持一定的一致性,以使您的生活更加轻松……以及使用您的api的人们的生活……不要跟从Microsoft。与RFC保持一致是一件好事
sdolgy 2011年

谢谢@sdolgy。向链接的文档做完简要介绍之后,我注意到了CONNECT动词的结尾。使用该方法进行RESTful身份验证会是一个糟糕的选择吗?
丹·拉格

不确定这是否是预期目的“此规范保留了方法名称CONNECT以便与可以动态切换到隧道(例如SSL隧道[44])的代理一起使用。” ...可能有助于在一个问题上发布另一个问题关于它的
stackexchange.com

2
@DanLugg您的应用程序可能没有CONNECT以SSL隧道的方式使用,但是想像一下,如果您的应用程序的使用者CONNECT使用以RFC中指定的方式实现的代理,那么请求可能不会传递给您应用。
Steve Buzonas 2014年

80

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体系结构的简洁文章。


9
好的答案,太糟糕了,这将支付党的后期罚款。复制粘贴的答案甚至还没有开始专门解决RESTful架构中这些动词的位置。
Todd Menier

1
您的链接已死。这是它的最后快照:web.archive.org/web/20160528151316/https
//…

29

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

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


谢谢@Quentin; OPTIONS这就是我所想的,而使用我现有的方法,这种实现将很容易。根据sdolgy的RFC引用,OPTIONS该格式未定义任何标准。是否假定响应格式与其他响应相同?(例如JSON,XML等
Dan Lugg

@Tomcat引用RFC:“可以使用内容协商来选择适当的响应格式。” 换句话说:响应应该是请求在标头中要求的。
Gordon
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.