You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered: