rest - 应该在 API 中返回自然键还是代理键？

Question

我第一次想到...

直到现在，我一直在我的 API 中使用自然键。例如，允许处理实体的 REST API，URL 类似于 /entities/{id}，其中 id 是用户已知的自然键(ID 传递给 POST 请求创建实体)。创建实体后，用户可以使用多个命令(GET、DELETE、PUT...)来操作实体。该实体还有一个由数据库生成的代理键。

现在，考虑以下顺序:

1. 用户创建 ID 为 1 的实体。(POST/entities 正文包含 ID 1)
2. 另一个用户删除实体 (DELETE/entities/1)
3. 同一位其他用户再次创建实体(POST/entities 正文包含 id 1)
4. 第一个用户决定修改实体(PUT/entities/1 with body)

在执行第4步之前，数据库中仍然有一个id为1的实体，但它不是第1步中创建的同一个实体。问题是第4步根据自然键识别要修改的实体对于已删除实体和新实体是相同的(而代理键不同)。因此，第 4 步会成功，用户永远不会知道它正在处理一个新实体。

我通常也在我的应用程序中使用乐观锁定，但我认为它在这里没有帮助。第一步之后，实体的版本字段为0。第三步之后，新实体的版本字段也为0。因此，版本检查将无济于事。使用时间戳字段进行乐观锁定是否正确？

将代理键返回给用户是“好的”解决方案吗？这样，用户总是向服务器提供代理键，服务器可以使用它来确保它在同一个实体上工作，而不是在新实体上工作？

您推荐哪种方法？

Answer 1

这取决于您希望用户如何使用您的 API。

REST API 应该尽量被发现。因此，如果在您的 API 中公开自然键有好处，因为它允许用户直接修改 URI 并进入新状态，那就去做吧。

一个很好的例子是类别或标签。我们可以有这些以下 URI；

GET /some-resource?tag=1    // returns all resources tagged with 'blue'
GET /some-resource?tag=2    // returns all resources tagged with 'red'

或

GET /some-resource?tag=blue    // returns all resources tagged with 'blue'
GET /some-resource?tag=red    // returns all resources tagged with 'red'

对于第二组用户来说显然更有值(value)，因为他们可以看到标签是真实的单词。然后，这允许他们在其中键入任何单词以查看返回的内容，而第一组不允许这样做:它限制了可发现性

另一个例子是订单

GET /orders/1   // returns order 1

或

GET /orders/some-verbose-name-that-adds-no-meaning    // returns order 1

在这种情况下，为订单添加一些冗长的名称以使其可被发现的值(value)不大。用户更可能希望先查看所有订单(或子集)并按日期或价格等进行过滤，然后选择一个订单进行查看

GET /orders?orderBy={date}&order=asc

额外的

在我们聊天讨论之后，您的问题似乎与版本控制和如何管理资源锁定有关。

如果您允许多个用户修改资源，您需要在每个请求和响应中发送一个版本号。进行任何更改时，版本号都会递增。如果请求在尝试修改资源时发送旧版本号，则抛出错误。

如果您允许重复使用相同的 URI，则可能会发生冲突，因为版本号始终从 0 开始。在这种情况下，您还需要发送一个 GUID(代理键)和一个版本号。或者不要使用自然 URI(请参阅上面的原始答案来决定何时执行此操作或不执行此操作)。

还有一个选项是不允许重用 URI。这实际上取决于用例和您的业务需求。重用 URI 可能没问题，因为在概念上它意味着同一件事。例如，如果您的计算机上有一个文件夹。删除文件夹并重新创建它与清空文件夹相同。从概念上讲，文件夹是相同的“事物”，但具有不同的属性。

用户帐户可能是重用 URI 不是一个好主意的领域。如果您删除一个帐户/accounts/u1，该 URI 应该被标记为已删除，并且任何其他用户都不能使用用户名 u1 创建一个帐户。从概念上讲，使用相同 URI 的新用户与前一个用户使用时不同。