休息 API 和 UUID [英] Rest API and UUID

问题描述

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

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

我的问题是:

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

解决方案

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

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

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

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

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

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

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

One of the reasons, and probably the main one, to use UUID is to avoid having a "centralized" point responsible for creating and assigning ids to resources.

That means that, for REST APIs, the clients could (and should) be able to generate, and give the UUID for a certain resource when they POST that specific resource for the first time. That would minimize problems related with successfully posting a resource for the first time but not getting the ID back as response (connectivity problems for example). That can result in a new post for some of the clients, generating duplicated resources.

My question are:

• Having UUID generated by clients and being exposed in the REST API is a best practice?
• Are there any other alternatives to that?

解决方案

REST does not really care if the UUID is generated by the server or by the client. It just needs a unique resource-identifier in form of an URI. What form the URI has, is not important to clients and servers - only that they are unique and may be obtained by clients (HATEOAS). You need of course also a resource on the server side which is able to create the sub-resource for you and understands that you want to provide the UUID instead of generating an own one. Instead of a UUID you could f.e. also use a url-encoded title of a blog-post or like this question a combination of hash-value and question-title 31584303/rest-api-and-uuid to uniquely identify a resource.

Generating a UUID by a client is in my opinion not used that ofen in practice, but I may be wrong on this matter. The actual question is rather, why should a client really provide an own UUID instead of letting the server create one? The client is, IMO, only interested in getting the data to the server and having some way to retrieve it at some later point, which will be provided through the location header returned in the response of a POST request.

If connection issues are an actual concern, you could let the client send an empty POST to create a resource and send back the location within the header. The content is than added via a PUT request.

There still can be some connection issues involved:

• request does not reach the server
• response does not reach the client

While the primer one is no issue for the client as well as for the server as no operation is executed and the request can simply be resent, the latter one will actually create a resource at the server side, though the link never reaches the client. Therefore the actual resource is in an unreferencable state unless you provide a way to iterate over all resources, which contains also the empty ones.

A server can have a cleanup thread in the back which removes empty resources after a given amount of time. If a client sends a further empty POST request but this time also receives the URI of the created resource, he can update the state of the resource via PUT. PUT is idempotent. If the server did not receive the request, the client can simply resent it. PUT has the semantic of updating existing or creating a new resource if it is not yet available. So, the server can create the resource in that case with the provided content. If the request did reach the server, a further update does not change the state of the resource.

这篇关于休息 API 和 UUID的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！