If the request did reach the server, a further update does not change the state of the resource. So, the server can create the resource in that case with the provided content. PUT has the semantic of updating existing or creating a new resource if it is not yet available. If the server did not receive the request, the client can simply resent it. 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. 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.Ī server can have a cleanup thread in the back which removes empty resources after a given amount of time. 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. You can choose the version of the UUID by calling different endpoints in UUID Generator API. UUID can be generated in different versions.
#Uuid generator api software#
There still can be some connection issues involved: A UUID Generator API is a tool that can quickly generate valid, unique UUID for information labelling and software testing purposes. The content is than added via a PUT 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 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. Generating a UUID by a client is in my opinion not used that ofen in practice, but I may be wrong on this matter. 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. 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. What form the URI has, is not important to clients and servers - only that they are unique and may be obtained by clients (HATEOAS). It just needs a unique resource-identifier in form of an URI.
REST does not really care if the UUID is generated by the server or by the client.
0 kommentar(er)
