happy to see your post. wanted to follow up on some HTTP-foo that I think makes supporting imdempotence writes easier for APIs.
HTTP has built-in features to make supporting idempotence easy (esp. handy w/ APIs.
services SHOULD:
1) support PUT /collection/{guid}, not POST /collection/ to create resources
2) require If-None-Match: * header on create (PUT) to prevent key collisions and return 412 Precondition Failed if the PUT fails
3) return ETag: {etag-hash} header on GET to ensure content idempotence
4) require If-Match: {etag-hash} header on update (PUT) to prevent content collisions and return 412 Precondition Failed if the PUT fails
clients SHOULD:
1) generate their own resource keys (you mention this)
2) send If-None-Match: * on create (PUT) & accept 412 Precondition Failed in response
3) send If-None-Match: {guid-hash} on GET & accept 204 No Content in response
4) send If-Match {guid-hash} headers on update (PUT) & accept 412 Precondition Failed in response
happy to see your post. wanted to follow up on some HTTP-foo that I think makes supporting imdempotence writes easier for APIs.
HTTP has built-in features to make supporting idempotence easy (esp. handy w/ APIs.
services SHOULD:
1) support
PUT /collection/{guid}, notPOST /collection/to create resources2) require
If-None-Match: *header on create (PUT) to prevent key collisions and return412 Precondition Failedif the PUT fails3) return
ETag: {etag-hash}header on GET to ensure content idempotence4) require
If-Match: {etag-hash}header on update (PUT) to prevent content collisions and return412 Precondition Failedif the PUT failsclients SHOULD:
1) generate their own resource keys (you mention this)
2) send
If-None-Match: *on create (PUT) & accept412 Precondition Failedin response3) send
If-None-Match: {guid-hash}on GET & accept204 No Contentin response4) send
If-Match {guid-hash}headers on update (PUT) & accept412 Precondition Failedin responsecheers
Could you please post a new article about above tips😊
Why?