How to handle retries

POST methods are by their nature are not idempotent calls but given the chaotic nature of networks there is a need to support the ability to retry POST calls if a response is not received. The problem with this is the server may have actually received the POST and processed the request, but for some reason, the client never received an acknowledgment.

GiftDeals supports making POST methods idempotent through the use if the requestid and the previousAttempts fields in the headers. By using specific values as described below you can safely make multiple POST calls and receive an​ idempotent response.

How to define the request-id and previousAttempts

Making the initial call

When first the first attempt at a POST there should be a unique requestid (we recommend using a UUID formatted as a plain string) and the previousAttempts should be 0.

These headers will tell GiftDeals this is the first attempt at the call

requestid: f938253a4c9d4ded89fe7265f72b1609
previousAttempts: 0

Calling after a timeout or no-response

If you do not receive​ a response from the server it is safe to make another POST call as long as you increment the previousAttempt header value and use the same requestid. This will tell the server this is another attempt and not create duplicate data if the previous request was already processed.

If the initial POST was processed by the server then the original response will be returned in the new POST call. This allows the client to safely retrieve the results. You can continue to increment the previousAttempt for each retry until you get back a response.

These headers will tell GiftDeals this is a retry attempt.

requestid: f938253a4c9d4ded89fe7265f72b1609
previousAttempts: 1

Calling without incrementing previousAttempt

If you make a do not increment the previousAttempt and do a POST multiple times then we will not make any changes and you will receive an error message back.