| 2014-02-12 04:27:31 |
aeva black |
description |
Proxies in between the user and our API tier may cache requests and re-issue them. This is a problem given our current resource-creation using "POST /v1/{type}/" -- if the proxy reissues this request, we'll create multiple resources, when the user only meant to create one.
A solution to this is to require clients to generate the resource identifier (eg, UUID) and then "PUT /v1/{type}/{uuid}". This would make resource-creation-requests idempotent and solve the above problem. In all other ways, this can be handled the same way on our side. |
Resource creation is done via "POST /v1/{type}" with a body containing some details about the resource. The resource identifier is generated on the server and returned to the client.
There are two potential problems:
If a POST request is received twice (eg, due to a network hiccup or a misconfigured proxy), multiple resources will be created instead of one, but the client is only expecting one response.
If a POST response is lost (eg, due to a network hiccup or the API service being killed), a resource will be created and the client will try again, generating a second resource.
In both cases, there are resources created for which the client does not receive a resource identifier.
Alternately, if the resource has a natural primary key (eg, a Port's MAC address), the client may get unexpected duplicate errors and need to search to find the identifier for the resource it was trying to create.
A solution to this is to require clients to generate the resource identifier (eg, UUID) and then "PUT /v1/{type}/{uuid}". This would make resource-creation-requests idempotent and solve the above problems. |
|
