Separare ricezione e lavorazione completata
Le garanzie dipendono dal fornitore. Stripe documenta duplicati possibili e ordine non garantito. Una risposta HTTP di successo deve corrispondere a ricezione duratura o lavorazione prevista, non solo all’arrivo in memoria.
| Situazione | Comportamento atteso | Prova utile |
|---|---|---|
| Stesso evento ricevuto due volte | Evitare il doppio effetto applicativo. | ID lavorato e risultato persistente. |
| Evento vecchio arriva dopo | Non sovrascrivere ciecamente uno stato recente. | Stato autorevole e regola di transizione. |
| Lavorazione pesante | Ricezione duratura e lavoro differito. | Stato della coda e risultato del worker. |
| Consegna mancante | Riconciliare e recuperare secondo il fornitore. | Divario individuato e correzione verificata. |
Costruire una ricezione verificabile
- Verificate HTTPS, firma e protezione dal replay secondo il protocollo. Stripe verifica la firma sul corpo grezzo; trasformare prima JSON può invalidare la verifica.
- Registrate durevolmente evento o lavorazione prima della conferma appropriata. Distinguete ID consegna, ID evento e chiave di idempotenza dell’azione.
- Testate duplicati, disordine, interruzione e riavvio del worker. Consultate lo stato autorevole dell’oggetto se un evento vecchio non permette una decisione sicura.
Organizzare recupero e riconciliazione
Documentate tentativi, tempi, eventi non lavorati e riconciliazione col fornitore. Una conferma rapida può nascondere un errore successivo. Monitorate anche l’azione finale e limitate segreti e dati personali nei registri.
Fonti primarie
Gestire in modo sicuro i webhook ripetuti.
Una notifica può essere ripetuta dopo un timeout o una risposta persa. L'affidabilità dipende dalla verifica dell'origine, da un identificatore di evento e da un'elaborazione che separa un nuovo messaggio da un duplicato.
- Verificare ogni richiesta utilizzando il meccanismo del provider.
- Testare i tentativi, i duplicati e l'ordine di arrivo modificato.
- Confermare in modo coerente dopo l'elaborazione o la messa in coda persistente.
Fonte primaria: IETF RFC 9457 — Problem Details for HTTP APIs. Metodo correlato: consultare la guida pratica.