Consequences of POST not being idempotent (RESTful API)

mibollma picture mibollma · Dec 21, 2012 · Viewed 15.8k times · Source

I am wondering if my current approach makes sense or if there is a better way to do it.

I have multiple situations where i want to create new objects and let the server assign an ID to those objects. Sending a POST request appears to be the most appropriate way to do that. However since POST is not idempotent the request may get lost and sending it again may create a second object. Also requests being lost might be quite common since the API is often accessed through mobile networks.

As a result i decided to split the whole thing into a two-step process. First sending a POST request to create a new object which returns the URI of the new object in the Location header. Secondly performing an idempotent PUT request to the supplied Location to populate the new object with data. If a new object is not populated within 24 hours the server may delete it through some kind of batch job.

Does that sound reasonable or is there a better approach?

Thanks

Answer

Aurélien picture Aurélien · Dec 28, 2012

The only advantage of POST-creation over PUT-creation is the server generation of IDs. I don't think it worths the lack of idempotency (and then the need for removing duplicates or empty objets).

Instead, I would use a PUT with a UUID in the URL. Owing to UUID generators you are nearly sure that the ID you generate client-side will be unique server-side.