pinning-services-api-spec
pinning-services-api-spec copied to clipboard
API should be idempotent
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>.