首页 文章

为什么仅为POST请求/ 201（创建）响应设置HTTP位置标头？

提问于
浏览 次
4

暂时忽略3xx响应，我想知道为什么HTTP位置标头仅与POST请求/ 201（创建）响应一起使用 .

来自RFC 2616 spec：

对于201（已创建）响应，Location是请求创建的新资源的位置 .

这是一种受到广泛支持的行为，但为什么不应该将其与其他HTTP方法一起使用？以JSON API spec为例：

它为JSON有效负载（not uncommon for RESTful APIs）内的当前资源定义了自引用链接 . 此链接包含在每个有效负载中 . 如果您通过POST创建一个新文档并且该值与有效负载中的自引用链接相同，则规范表明您 MUST 包含HTTP位置标头，但这是POST所需的 ONLY . 如果您可以使用HTTP位置标头，为什么还要使用自引用链接的自定义格式？

注意：对于HAL，JSON Hyper-Schema或其他标准，这不是't specific to JSON API. It'相同 .

注意2：它甚至不是特定于HTTP位置标头，因为它与HTTP链接标头相同 . 正如您所看到的，JSON API，HAL和JSON Hyper-Schema不仅定义了自引用链接的约定，还表达了有关资源的相关资源或可能的操作的信息 . 但似乎他们都可以使用HTTP链接头 . （如果他们不想使用HTTP位置标头，他们甚至可以将自引用链接放入HTTP链接头 . ）

我不想咆哮，它似乎只是某种“重新发明轮子” . 它似乎也是非常有限的：如果你只是使用HTTP位置/链接头，那么你在HTTP接受头中询问JSON，XML或其他什么并不重要，你会获得关于你的资源的有用的元信息HEAD请求，如果您使用JSON API，HAL或JSON Hyper-Schema，则不包含链接 .

json rest hateoas json-api hal-json

2 回答

  • 5

    Location 标头的语义是't that of a self-referencing link, but of a link the user-agent should follow in order to complete the request. That makes sense in redirects, and when you create a new resource that will be in a new location you should go to. If your request is already completed, meaning you already have a full representation of the resource you wanted, it doesn' t返回 Location 是有意义的 .

    可以认为 Link 标头在语义上等同于超文本链接，但是当媒体类型不是超媒体感知时，它应该用于引用与给定资源相关的元数据，因此它不会替换相关链接的功能 . RESTful API中的资源 .

    在资源表示中需要自定义链接格式是将资源与底层实现和协议分离的必要条件 . REST不与HTTP耦合，可以使用任何有效URI方案的协议 . 如果您决定对所有链接使用 Link 标头，那么您将耦合到HTTP .

    假设您提供了一个FTP链接供客户遵循 . 在那种情况下 Link 会在哪里？

    回复于
  • 6

    Location标头的语义取决于状态代码 . 对于201，它链接到新创建的资源，但在3xx请求中它可以具有多个（尽管类似的）含义 . 我认为这就是为什么通常会避免其他用法 .

    替代方案是Content-Location标头，它始终具有一致的含义 . 它告诉客户端规范URL所请求的资源 . 它纯粹是信息性的（与位置相反，预计将由客户处理） .

    因此，Content-Location标头看起来更像是自引用链接 . 但是，Content-Location也有no defined behavior for PUT and POST . 它似乎也很少使用 .

    这篇博文Location vs Content-Location是一个很好的比较 . 这是一个引用：

    最后，两个 Headers 都不适用于通用链接 .

    总而言之，要求身体中的标准化，自我链接似乎是个好主意 . 它避免了客户端的很多混乱 .

    回复于

相关问题