休息 API 和 UUID

Question

使用 UUID 的原因之一，也可能是主要原因之一，是为了避免让“集中”点负责创建和分配 id 给资源。

这意味着，对于 REST API，客户端可以（并且应该）能够在他们第一次 POST 特定资源时为特定资源生成和提供 UUID。这将最大限度地减少与第一次成功发布资源但未将 ID 作为响应取回相关的问题（例如连接问题）。这可能会导致某些客户端发布新帖子，从而产生重复的资源。

我的问题是：

• 由客户端生成 UUID 并在 REST API 中公开是最佳实践吗？
• 还有其他替代方法吗？

Answer 1

REST 并不真正关心 UUID 是由服务器还是由客户端生成。它只需要一个 URI 形式的唯一资源标识符。URI 具有什么形式，对于客户端和服务器并不重要 - 只是它们是唯一的并且可以由客户端（HATEOAS）获取。您当然还需要服务器端的资源，该资源能够为您创建子资源并了解您想要提供 UUID 而不是生成自己的 UUID。除了 UUID，您还可以使用博客文章的 url 编码标题，或者像这个问题一样使用哈希值和问题标题的组合31584303/rest-api-and-uuid来唯一标识资源。

在我看来，由客户生成 UUID 在实践中并不常用，但我在这件事上可能是错误的。实际的问题是，为什么客户端真的应该提供自己的 UUID 而不是让服务器创建一个？客户端，IMO，只对将数据发送到服务器感兴趣，并在稍后的某个时间点以某种方式检索它，这将通过在 POST 请求的响应中返回的位置标头提供。

如果连接问题是一个实际问题，您可以让客户端发送一个空的 POST 来创建一个资源并发回标头中的位置。然后通过 PUT 请求添加内容。

仍然可能涉及一些连接问题：

• 请求未到达服务器
• 响应没有到达客户端

虽然第一部分对于客户端和服务器都没有问题，因为没有执行任何操作并且可以简单地重新发送请求，但后者实际上会在服务器端创建一个资源，尽管链接永远不会到达客户端。因此，实际资源处于不可引用状态，除非您提供一种迭代所有资源的方法，其中也包含空资源。

服务器可以在后面有一个清理线程，它会在给定的时间后删除空资源。如果客户端再发送一个空的 POST 请求，但这次也收到了所创建资源的 URI，他可以通过PUT. PUT 是幂等的。如果服务器没有收到请求，客户端可以简单地重新发送它。PUT 具有更新现有资源或创建新资源（如果尚不可用）的语义。因此，在这种情况下，服务器可以使用提供的内容创建资源。如果请求确实到达了服务器，进一步的更新不会改变资源的状态。