合并资源的 HTTP 状态代码的最佳实践是什么？

Question

我们有一个为人们服务的 REST API 端点

api/person/{ID}

。有时数据库中存在重复项，这些重复项在被发现时会被合并，因此其中一个条目将被删除，并将其数据与另一个条目的数据合并。目前，当您请求删除人员且未提及新 ID 时，会提供

404

。显然，这对于使用 API 来让人员了解最新情况的客户来说并不理想。

我们有这些合并的日志，因此我们能够提供新的 ID – 但如何提供？

据我所知，可能性有：

• 发送 HTTP 状态

  404

  并在正文中提及新 ID
  • 客户端开发人员必须显式从主体获取 ID 并在其端处理合并
• 发送 HTTP 状态

  301

  并在

  location

  标头中发送新资源 URI
  • 我在其他API中见过这个，但它允许客户端将HTTP方法更改为

    GET

  • 一些客户端可能会自动遵循

    location

    并且客户端开发人员可能不知道，他们也必须合并其端的实体
• 发送 HTTP 状态

  308

  并在

  location

  标头中发送新资源 URI
  • 客户端必须对新 URI 使用相同的 HTTP 方法，这似乎是正确的 - 但客户端是否应该真正自动发送

    POST

    /

    DELETE

    /

    PATCH

    /等。请求新资源？这可能会导致意想不到的后果
  • 一些客户端可能会自动遵循

    location

    并且客户端开发人员可能不知道，他们也必须合并其端的实体

A

308

似乎是最正确的解决方案，但它也是最好的吗？在这种情况下，最佳做法是什么？

Answer 1

HTTP 状态代码是通用通过网络传输文档域的元数据。

因此，消息真正描述的是您的资源，而不是底层数据模型（从 HTTP 的角度来看，这是一个隐藏的实现细节）。

---

一个完全合理的选择是继续通过“旧”URI 接受请求

GET /api/person/1

200 OK
Content-Location: /api/person/2
Link: </api/person/2>; rel="self"

---

如果您想要与通用客户端通信的是应使用新 URI 代替旧 URI，则带有 Location 标头的 308 永久重定向 是合适的。