Making PUT create request idempotent in REST API

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?


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.

链接地址: http://www.djcxy.com/p/7102.html

上一篇: 选择:无“和Firefox中的奇怪行为

下一篇: 使用PUT在REST API中创建请求idempotent