使用UUID的原因之一，也可能是主要的原因之一是避免使用＆＃34;集中式＆＃34;负责创建和分配资源的ID。
这意味着，对于REST API，客户端可以（并且应该）能够生成并在第一次对该特定资源进行POST时为特定资源提供UUID。这样可以最大限度地减少与首次成功发布资源相关的问题，但不会将ID作为响应返回（例如连接问题）。这可能会导致某些客户端发布新帖子，从而生成重复的资源。
我的问题是：
答案 0 :(得分：4)
REST并不关心UUID是由服务器还是客户端生成的。它只需要一个URI形式的唯一资源标识符。
URI的形式对客户端和服务器来说并不重要 - 只有它们是唯一的并且可以由客户端（HATEOAS）获得。当然，您还需要服务器端的资源，它能够为您创建子资源，并了解您要提供UUID而不是生成自己的UUID。而不是UUID你可以f.e.也可以使用博客文章的网址编码标题，或者将此问题与哈希值和问题标题31584303/rest-api-and-uuid结合使用，以唯一标识资源。
客户生成UUID在我看来并没有在实践中使用，但我在这件事上可能是错的。实际的问题是，为什么客户真的应该提供自己的UUID而不是让服务器创建一个？客户端是IMO，只对将数据提供给服务器并有一些方法在稍后的某个时间点检索它感兴趣，这将通过POST请求的响应中返回的位置头提供。
如果连接问题是一个实际问题，您可以让客户端发送一个空POST来创建资源并发回标头中的位置。然后通过PUT请求添加内容。
仍然可能涉及一些连接问题：
虽然引导对客户端和服务器都没有问题，因为没有执行任何操作并且可以简单地重新发送请求，后者实际上将在服务器端创建资源，尽管链接永远不会到达客户端。因此，实际资源处于不可报告的状态，除非您提供迭代所有资源的方法，其中也包含空资源。
服务器可以在后面有一个清理线程，它会在给定的时间后删除空资源。如果客户端发送了另一个空的POST请求，但这次也接收到创建的资源的URI，他可以通过PUT更新资源的状态。 PUT是幂等的。如果服务器没有收到请求，客户端可以简单地重新发送请求。 PUT具有更新现有语义或创建新资源（如果尚未可用）的语义。因此，服务器可以使用提供的内容在该情况下创建资源。如果请求确实到达服务器，则进一步更新不会更改资源的状态。