pinning-services-api-spec icon indicating copy to clipboard operation
pinning-services-api-spec copied to clipboard

API should be idempotent

Open guseggert opened this issue 3 years ago • 0 comments

Currently there is no specified way to make POST /pins nor POST /pins/{requestId} idempotent, so if there's some transient issue e.g. reading the pinning service response and the client needs to retry, it may create two potentially-expensive pinning requests when only one was desired.

For POST /pins, an optional requestId field could be added which is used as an idempotency token. For POST /pins/{requestId}, it is explicitly not idempotent for the requestId, so without redesigning the API, it'd probably need a separate field for an idempotency token with some token expiration period, or use an implicit idempotency key like <requestId, CID, name, metadata>.

guseggert avatar May 28 '22 15:05 guseggert