如果我的 API 已按照 HAL 规范返回自链接，我是否应该对创建的资源使用位置标头？

Question

我正在关注一些博客和 SO 问题，他们建议Location服务器返回一个带有201 created响应的标头。Spring-data-rest还返回标头中创建的资源位置Location。

但真的有必要吗？？

考虑这个POST请求： curl -d '{..data}' -H "Content-Type: application/json" -X POST http://localhost:3000/persons
响应：

{
  "name": "hero",
  "_links": {
    "self": {
      "href": "http://localhost:8081/persons/1"
    },
    "person": {
      "href": "http://localhost:8081/persons/1"
    }
  }
}

既然响应中包含创建的资源的绝对位置self和person链接，为什么Location还需要标头呢？

Answer 1

如果您想符合HTTP 规范 (RFC 7231)，您应该返回Location响应标头201 Created：

如果由于成功处理 POST 请求而在源服务器上创建了一个或多个资源，则源服务器应该发送一个 201（已创建）响应，其中包含一个 Location 标头字段，该字段为创建的主要资源提供标识符（第 7.1 节） .2) 以及在引用新资源时描述请求状态的表示。

某些客户端实现将在此类前提下运行，如果您违反 HTTP 规范，它们可能无法与您的 API 正确交互。

此外，您必须区分一些特定于媒体类型的表示内容和一些通用的请求响应元数据。标Location头属于响应的元数据。不理解某种表示格式的客户端仍会知道服务器能够在给定的 URI 处存储内容。

考虑这样一个场景：任意客户端向服务器发送数据，服务器以客户端无法理解的表示格式存储该数据（服务器允许这样做），客户端应该如何确定数据的位置或检索数据未来的数据？由于缺乏有关返回的表示格式的知识，并且通过从标头中省略此类信息，客户端将无法处理响应，并且无法轻松地再次请求此数据。通过引入一个表示中立的提示，即每个行为良好的实现都应该遵循客户端，至少可以理解这一点。它可能仍然无法正确处理响应负载，但它知道数据在相应位置可用。

客户端和服务器应协商要交换消息的实际媒体类型，以提高互操作性。因此，媒体类型描述了可能出现在交换的消息中的元素的语法和语义以及处理请求的规则集，即某些元素可能仅出现在某些条件下。application/json除了某些键值对包含在大括号式表示法中之外，仅交换并不能向客户端提供有关如何处理数据的大量信息。虽然hal+json添加了 URI 的语义，但它没有指定用于返回创建的资源的密钥，因为 HTTP 规范已经涵盖了这一点。

关于REST，你可以以Web为例来设计客户端和服务器之间的交互流程。这里的前提应该始终是服务器通过类似表单的表示格式和提供的链接来教导客户端下一步可以做什么。REST 架构的最终目标是客户端与服务器的解耦，允许服务器在未来自由发展而不会破坏客户端。然而，这需要仔细设计，因为很容易引入意外的耦合。