为什么HTTP位置标头只为POST请求/201(创建)响应设置？
忽略3xx响应一会儿，我想知道为什么HTTP位置标头只与POST请求/201 (Created)响应一起使用。
来自RFC 2616规范
对于201 (已创建)响应，该位置是请求创建的新资源的位置。
这是一种被广泛支持的行为，但为什么不与其他HTTP方法一起使用呢？以JSON API规范为例：
它为JSON有效负载(RESTful API并不少见)中的当前资源定义了一个自引用链接。此链接包含在每个有效负载中。规范指出，如果通过POST创建新文档，并且值与有效负载中的自引用链接相同，则必须包含header，但这是POST所需的专用。如果您只需要使用HTTP位置标头，为什么要为自引用链接使用自定义格式呢？
注意:这并不是JSON所特有的。硬件、JSON超模式或其他标准也是如此。
注2:它甚至不特定于HTTP位置标头，因为它与HTTP链接标头相同。如您所见，JSON、HAL和JSON Schema不仅定义了自引用链接的约定，而且还表示了有关相关资源或资源可能的操作的信息。但是，它们似乎都可以只使用HTTP链接头。(如果不想使用HTTP位置标头，他们甚至可以将自引用链接放入HTTP链接头中。)
我不想咆哮，这似乎是某种“重新发明方向盘”。它似乎也非常有限:如果您只使用HTTP位置/链接标头，那么如果您在HTTP accept报头中请求JSON、XML或其他任何内容，那么您将获得有用的元信息--关于HEAD请求中的资源的信息，如果您使用JSON API、HAL或JSON Hyper-Schema，这些信息将不包含链接。
回答 2
Stack Overflow用户
发布于 2014-06-04 16:31:23
Location头的语义不是自引用链接的语义，而是用户代理为完成请求而应遵循的链接的语义。这在重定向中是有意义的，当您创建一个新的资源时，您应该去一个新的位置。如果您的请求已经完成，这意味着您已经有了所需资源的完整表示，返回一个Location是没有意义的。
Link标头在语义上可以被视为等同于超文本链接，但是当媒体类型不知道超媒体时，它应该用于引用与给定资源相关的元数据，因此它不会取代RESTful API中指向相关资源的链接的功能。
需要在资源表示中使用自定义链接格式，这是因为需要将资源与底层实现和协议分离开来。REST不耦合到HTTP，任何有有效URI方案的协议都可以使用。如果您决定对所有链接使用Link头，则需要耦合到HTTP。
假设您为客户端提供了一个FTP链接。在这种情况下，Link会在哪里？
Stack Overflow用户
发布于 2014-06-04 22:49:12
位置头的语义取决于状态代码。对于201，它链接到新创建的资源，但在3xx请求中，它可以具有多个含义(尽管类似)。我认为这就是为什么在其他用法中通常都避免使用它。
另一种方法是内容定位头，它总是有一个一致的含义。它告诉客户端它所请求的资源的规范URL。它是纯粹的信息(与预期由客户端处理的位置相反)。
因此，内容位置标题似乎更接近自引用链接。然而，内容位置也有没有为PUT和POST定义行为。它似乎也很少被使用。
这个博客发布位置与内容位置是一个很好的比较。以下是一句名言：
最后，两个标头都不是用于通用链接的.
总之，要求身体内有一个标准化的自我链接似乎是个好主意。它避免了客户端的许多混乱。
https://stackoverflow.com/questions/24039340
复制相似问题
腾讯云开发者
