RESTful API方法; 头和选项

Question

RESTful API方法; 头和选项

Dan*_*ugg 82 php api rest http

我正在写一个RESTful API模块在PHP的应用程序,并且我对动词有点混合HEAD和OPTIONS.

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

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

如果有人能澄清*这些动词,那将非常感激.

_{*澄清是关于重新使用HTTP谓词的RESTful API架构.我既然来实现这两个HEAD和OPTIONS应不被重新利用,而是表现可以预见任何HTTP应用程序应该.哦,我们如何在2年内成长.}

Answer 1

Yur*_*nyy 56

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

Run Code Online (Sandbox Code Playgroud)

头

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

Run Code Online (Sandbox Code Playgroud)

OPTIONS 确定资源支持哪些HTTP方法,例如我们可以删除它还是通过PUT更新它？

HEAD检查资源是否已更改.这在维护资源的缓存版本时很有用

HEAD 在进行可能代价高昂的检索之前,检索有关资源的元数据,例如其媒体类型或其大小

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

以下是关于HEAD和OPTIONS如何适应RESTful架构的简洁文章.

很好的答案,太糟糕了,它将支付迟到的罚款.复制粘贴的接受答案甚至没有开始专门解决这些动词在RESTful架构中的位置. (4认同)
你的链接已失效。这是它的最后一个快照：https://web.archive.org/web/20160528151316/https://www.safaribooksonline.com/blog/2013/05/29/tip-probe-web-resources-head-options-rest / (2认同)

Answer 2

sdo*_*lgy 49

根据: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请求的响应可以是可缓存的,因为响应中包含的信息可以用于从该资源更新先前缓存的实体.如果新的字段值指示缓存的实体从当前实体的不同(如将在内容长度,内容,MD5,ETag的或上次修改的变化来表示),那么缓存必须把缓存条目为陈旧.

如果你正在构建自己的,我认为你是,你应该尝试与文档标准保持一致,以使你的生活更轻松......而那些消费你的api ...的人不会跟随微软.RFC是一个很好的选择 (2认同)
@DanLugg您的应用程序可能没有以SSL隧道的方式使用"CONNECT",但想象一下如果您的应用程序的使用者拥有以RFC中指定的方式实现"CONNECT"的代理会发生什么,请求可能会发生不会传递给您的申请. (2认同)

Answer 3

Que*_*tin 24

OPTIONS会告诉您诸如"此资源允许哪些方法"之类的内容.

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

归档时间：	14 年，3 月前
查看次数：	72863 次
最近记录：	6 年，8 月前