为什么仅为POST请求/ 201(创建)响应设置HTTP位置标头？
渡船毛_699 发布于 2023-01-11 17:27暂时忽略3xx响应,我想知道为什么HTTP位置标头仅与POST请求/ 201(创建)响应一起使用.
来自RFC 2616规范:
对于201(已创建)响应,Location是请求创建的新资源的位置.
这是一种受到广泛支持的行为,但为什么不应该将其与其他HTTP方法一起使用？以JSON API规范为例:
它为JSON有效负载内的当前资源定义了一个自引用链接(对于RESTful API来说并不罕见).此链接包含在每个有效负载中.该规范说,你必须包括HTTP标头的位置,如果你创建通过POST,且这个值是一样的,在有效载荷自参考链接一个新的文件,但是这仅需要POST.如果您可以使用HTTP位置标头,为什么还要使用自引用链接的自定义格式？
注意:这不是特定于JSON API的.这是对同一HAL,JSON的Hyper-模式或其他标准.
注意2:它甚至不是特定于HTTP位置标头,因为它与HTTP链接标头相同.正如您所看到的,JSON API,HAL和JSON Hyper-Schema不仅定义了自引用链接的约定,还表达了有关资源的相关资源或可能的操作的信息.但似乎他们都可以使用HTTP链接头.(如果他们不想使用HTTP位置标头,他们甚至可以将自引用链接放入HTTP链接头.)
我不想咆哮,它似乎只是某种"重新发明轮子".它似乎也是非常有限的:如果你只是使用HTTP位置/链接头,那么你在HTTP接受头中询问JSON,XML或其他什么并不重要,你会获得关于你的资源的有用的元信息HEAD请求,如果您使用JSON API,HAL或JSON Hyper-Schema,则不包含链接.
-
Location标头的语义取决于状态代码.对于201,它链接到新创建的资源,但在3xx请求中它可以具有多个(尽管类似的)含义.我认为这就是为什么通常会避免其他用法.
替代方案是Content-Location标头,它始终具有一致的含义.它告诉客户端规范URL所请求的资源.它纯粹是信息性的(与位置相反,预计将由客户处理).
因此,Content-Location标头看起来更像是自引用链接.但是,Content-Location也没有针对PUT和POST的已定义行为.它似乎也很少使用.
此博客帖子位置与内容位置是一个很好的比较.这是一个引用:
最后,两个标题都不是用于通用链接.
总而言之,要求身体中的标准化,自我链接似乎是个好主意.它避免了客户端的很多混乱.
2023-01-11 17:30 回答
凰媓_935 -
Location标头的语义不是自引用链接的语义,而是用户代理应该遵循的链接以完成请求.这在重定向中是有意义的,当您创建一个将位于新位置的新资源时,您应该去.如果您的请求已经完成,这意味着您已经拥有了所需资源的完整表示,那么返回a是没有意义的Location.该
Link头可以被认为是语义上等同于一个超文本链接,但它应该被用来引用相关的元数据,以给定的资源时,媒体类型是不是超媒体感知的,所以它不会取代一个链接的功能,相关资源在RESTful API中.在资源表示中需要自定义链接格式是将资源与底层实现和协议分离的必要条件.REST不与HTTP耦合,可以使用任何有效URI方案的协议.如果您决定
Link对所有链接使用标头,那么您将耦合到HTTP.假设您提供了一个FTP链接供客户遵循.
Link在那种情况下会在哪里？2023-01-11 17:31 回答
mobiledu2502873093
京公网安备 11010802041100号