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>.
Currently there is no specified way to make
POST /pinsnorPOST /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 optionalrequestIdfield could be added which is used as an idempotency token. ForPOST /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>.