Rest API and UUID -

one of reasons, , main one, use uuid avoid having "centralized" point responsible creating , assigning ids resources.

that means that, rest apis, clients (and should) able generate, , give uuid resource when post specific resource first time. minimize problems related posting resource first time not getting id response (connectivity problems example). can result in new post of clients, generating duplicated resources.

my question are:

• having uuid generated clients , being exposed in rest api best practice?
• are there other alternatives that?

rest not care if uuid generated server or client. needs unique resource-identifier in form of uri. form uri has, not important clients , servers - unique , may obtained clients (hateoas). need of course resource on server side able create sub-resource , understands want provide uuid instead of generating own one. instead of uuid f.e. use url-encoded title of blog-post or question combination of hash-value , question-title 31584303/rest-api-and-uuid uniquely identify resource.

generating uuid client in opinion not used ofen in practice, may wrong on matter. actual question rather, why should client provide own uuid instead of letting server create one? client is, imo, interested in getting data server , having way retrieve @ later point, provided through location header returned in response of post request.

if connection issues actual concern, let client send empty post create resource , send location within header. content added via put request.

there still can connection issues involved:

• request not reach server
• response not reach client

while primer 1 no issue client server no operation executed , request can resent, latter 1 create resource @ server side, though link never reaches client. therefore actual resource in unreferencable state unless provide way iterate on resources, contains empty ones.

a server can have cleanup thread in removes empty resources after given amount of time. if client sends further empty post request time receives uri of created resource, can update state of resource via put. put idempotent. if server did not receive request, client can resent it. put has semantic of updating existing or creating new resource if not yet available. so, server can create resource in case provided content. if request did reach server, further update not change state of resource.