An interesting thing to consider with merry is idempotent API design when working with server/client communication and, most importantly, failures.
PUT and DELETE request normally should deal with the requests sent over to idempotent server endpoints. Using an idempotent key (or a unique identifier generated by the client on each request) to make sure the operation processed by the endpoints only happens once is something to be considered.
The question here is whether or not merry should handle some sort of check for the idempotent keys. Alternatively, should we document this pattern as part of our guidebook.
An interesting thing to consider with merry is idempotent API design when working with server/client communication and, most importantly, failures.
PUT
andDELETE
request normally should deal with the requests sent over to idempotent server endpoints. Using anidempotent key
(or a unique identifier generated by the client on each request) to make sure the operation processed by the endpoints only happens once is something to be considered.The question here is whether or not merry should handle some sort of check for the idempotent keys. Alternatively, should we document this pattern as part of our guidebook.
Thankssss ^___^
reference: stripe engineering blog