Reprises et idempotence
GuideDéveloppeursDepuis la version 0.2.0
Sur cette page
Ce que la passerelle rejoue pour vous, et ce que vous pouvez rejouer sans risque.
Côté produit : Contrôle du trafic et quotas ; côté exploitation : Résilience.
Ce que la passerelle rejoue
| Règle | Détail |
|---|---|
| Méthodes | Idempotentes (GET, HEAD, PUT, DELETE), ou toute requête qui porte Idempotency-Key |
| Causes | Connexion refusée ou coupée, 502, 503 de l'API - jamais un 4xx, jamais un délai de réponse |
| Limites | Au plus deux tentatives, sous un budget de reprises, et jamais après le premier octet envoyé |
Ce que vous pouvez rejouer
| Réponse | Lecture | Écriture |
|---|---|---|
429, 503 |
Après Retry-After |
Après Retry-After |
502, 504 |
Oui | Seulement avec la même Idempotency-Key, que l'API (ou le courtier) déduplique |
4xx autre |
Non : corrigez la requête | Non |
Envoyez une Idempotency-Key unique (un UUID) sur chaque écriture ; elle est relayée à l'API. Sur une
porte de publication, elle peut être exigée (428) et devient l'id de l'évènement.