Making PUT create request idempotent in REST API

1
votes

My goal is to make idempotent /create REST API which is implemented as PUT verb.

Idempotent RFC states:

Idempotent methods are distinguished because the request can be
repeated automatically if a communication failure occurs before the
client is able to read the server's response. For example, if a
client sends a PUT request and the underlying connection is closed
before any response is received, then the client can establish a new
connection and retry the idempotent request. It knows that repeating the request will have the same intended effect, even if the original
request succeeded, though the response might differ.

PUT RFC states:

If the target resource does not have a current representation and the PUT successfully creates one, then the origin server MUST inform the
user agent by sending a 201 (Created) response. If the target
resource does have a current representation and that representation
is successfully modified in accordance with the state of the enclosed representation, then the origin server MUST send either a 200 (OK) or a 204 (No Content) response to indicate successful completion of the
request.

Assuming that /create stores the created resource in DB, should it return 201 on first creation and 200 on retried /create? Should retried /create store the same resource in DB all over again to conform with PUT RFC?

1
resthttpputidempotent
Use POST for save, and PUT to update. – Ayush Gupta
my goal is to make PUT /create idempotent. It means that it can be retried – rok
How will you know whether to create a resouce or update it? – Ayush Gupta
i will check if one exists with the same id – rok
And you will you get the ID? Just curious, because PUT / and PUT /:id are 2 different resources – Ayush Gupta

1 Answers

2
votes

So this question is a bit confused. Let's see if we can untangle it.

PUT /create

abcde

Says roughly: replace the state of /create with representation abcde. In other words, the semantics of the message are something along the lines of 

store(key => "/create", value => "abcde")

Notice that processing this message twice produces the same effect as processing the message once. 

store(key => "/create", value => "abcde")
store(key => "/create", value => "abcde")

Notice that we're being very specific about the key that we are using here; PUT relates to the state of the target resource; PUT /create is a message requesting that we modify /create, not a request that we create some other resource.

Assuming that /create stores the created resource in DB, should it return 201 on first creation and 200 on retried /create?

Yes.

Should retried /create store the same resource in DB all over again to conform with PUT RFC?

If the resource already has the requested representation, you don't need to store it again.