Stripe kujton kërkesën tuaj kur përgjigja zhduket

Çfarë mbulon kjo video

• Idempotenca ka të bëjë me efektin e synuar të përsëritjes së një operacioni. API v1 e Stripe shton një kontratë të dokumentuar për rikthimin e përgjigjeve të ruajtura.
• Një rishfaqje e të njëjtit veprim logjik përdor të njëjtin çelës dhe parametra. Vazhdoni çelësin e operacionit përmes thirrjeve të ndara të SDK ose rinisjeve të aplikacionit; një veprim vërtet i ri ka nevojë për çelësin e vet.
• Pasi fillon ekzekutimi i pikës fundore, Stripe API v1 ruan statusin dhe trupin e kërkesës së parë, duke përfshirë gabimet 500, dhe kthen atë përgjigje të ruajtur në rishfaqje.
• Parametrat e ndryshuar me të njëjtin çelës prodhojnë një mosmarrëveshje. Dështimet e vërtetimit dhe konfliktet e ekzekutimit të njëkohshëm nuk ruajnë asnjë rezultat idempotent për atë tentativë dhe mund të rishfaqen.
• Stripe i ruan çelësat e API v1 për të paktën 24 orë dhe mund t'i heqë më pas. Kufizoni rishfaqjet e pazgjidhura të rrjetit në 24 orët e para, pastaj ndaloni dhe pajtojeni para se të përsëritni operacionin.
• Një gabim 500 i ruajtur mund të vazhdojë të rishfaqet pasi të rikthehet lidhja. Operacioni origjinal mund të ketë efekte anësore; përdorni objektin përkatës, kërkesën e Panelit dhe webhooks për të përcaktuar rezultatin e tij.
• API v2 përdor semantikë të ndryshme rishfaqjeje. Një çelës nuk vendos dorëzim universal saktësisht një herë për emailin, inventarin dhe çdo operacion të bazës së të dhënave lokale.

Transkript i përkthyer

Përkthyer nga tregimi origjinal në anglisht. Audio dhe titrat e disponueshme kontrollohen nga YouTube.

A e anuloi një mbarim kohe pagesën tuaj?

0:00 Mendoni se një mbarim i kohës do të thotë që pagesa juaj dështoi. Serveri mund të përfundojë ndërsa përgjigja zhduket, duke e lënë checkout-in tuaj të shfaqë me siguri absolutisht asgjë. Pse mund të tarifohet sërish një rishfaqje? Si e kujton Stripe një tentativë? Kur duhet të ndaloni rishfaqjet? Dhe mbani parasysh një detaj të shëmtuar. Një gabim i kujtuar mund t'i mbijetojë problemit të rrjetit.

0:17 Do t'i kthehemi kësaj. Ky është The Daily Diff, nën kapuç.

Çfarë identifikon një çelës idempotence?

0:21 Idempotenca do të thotë që përsëritja e një operacioni ka të njëjtin efekt të synuar si kryerja e tij një herë. Një çelës idempotence etikon një veprim logjik. Versioni i parë i API-së së Stripe e njeh atë etiketë në rishfaqje dhe riprodhon një përgjigje të ruajtur. Imagjinoni të blini një kafe. Stripe përfundon kërkesën tuaj të pagesës, dhe përgjigja humbet gjatë kthimit në shtëpi. Klienti sheh një rrotullues. Banka e tyre mund të ketë një interpretim më emocionues. Një kërkesë krijimi e pambrojtur mund të përsërisë efektin anësor.

Si e bën të sigurt të njëjtin çelës një rishfaqje?

0:45 Ngjisni një çelës unik para tentativës së parë dhe mbajeni atë për rishfaqjet. Nëse aplikacioni juaj riniset, ruani atë çelës me operacionin në regjistrat tuaj. Për API versionin një të Stripe, sapo fillon ekzekutimi i pikës fundore, ruhet statusi dhe trupi i kërkesës së parë. Dërgoni sërish të njëjtin çelës dhe parametra, dhe Stripe kthen përgjigjen e ruajtur. Kafeja mbetet në vend ndërsa fatura e saj udhëton sërish.

Çfarë saktësisht ruan Stripe?

1:07 Këtu është formulimi aktual i Stripe. Rishfaqjet me të njëjtin çelës kthejnë përgjigjen e ruajtur, duke përfshirë gabimet pesëqind. Dokumentacioni bën më shumë punë sesa ndihmësi juaj i rishfaqjes i emëruar me optimizëm. Klienti troket sërish. Aplikacioni juaj vendos nëse kjo rifillon blerjen në pritje apo fillon një tjetër. Një kafe vërtet e re merr një çelës të ri. Një çelës i ri për çdo rishfaqje të rrjetit e mposht mbrojtjen.

1:27 Parametra të ndryshëm me të njëjtin çelës shkaktojnë një mosmarrëveshje.

Çfarë ndodh kur kërkesa ndryshon?

1:30 Nëse parametrat dështojnë në vërtetim, ose një kërkesë tjetër me atë çelës është ende duke u ekzekutuar, Stripe nuk ruan asnjë rezultat idempotent për atë tentativë. Këto kërkesa mund të rishfaqen. Një kërkesë garash merr një konflikt. Këto janë rregullat e versionit një. Versioni i dytë sillet ndryshe. Një header nuk mund të premtojë dorëzim saktësisht një herë në të gjithë sistemin tuaj. Email, inventari dhe baza juaj e të dhënave kanë nevojë secila për trajtimin e dështimeve.

1:52 Çelësi mbron operacionin brenda fushës së tij të dokumentuar. Stripe i ruan çelësat e versionit një për të paktën njëzet e katër orë dhe mund t'i heqë

Sa kohë është i sigurt rezultati i kujtuar për t'u rishfaqur?

1:59 më pas. Një çelës i hequr mund të ekzekutojë një kërkesë të re. Mbajini rishfaqjet e pazgjidhura brenda ditës së parë. Përtej kësaj, ndaloni dhe pajtojeni rezultatin origjinal. Përdorni zbritje eksponenciale dhe dridhje për t'i dhënë serverit hapësirë frymëmarrjeje. Përndryshe, rishfaqjet formojnë një radhë jashtë një dyqani kafeje që po digjet. Libraritë e Stripe trajtojnë rishfaqjet, por kontrolloni parazgjedhjet e librarisë tuaj. Ai gabim i ngjitur është kurthi.

Pse mund të vazhdojë të kthehet një gabim i kujtuar?

2:20 Një përgjigje e ruajtur pesëqind vazhdon të rishfaqet pasi rikthehet lidhja. Operacioni origjinal mund të ketë prodhuar efekte anësore. Zgjidhni rezultatin e tij duke përdorur objekte, Panelin dhe webhooks. Një çelës i ri mund të përsërisë veprimin. Nëse preferoni ta lexoni këtë sesa të më dëgjoni ta them, diff-i arrin në kutinë tuaj hyrëse çdo mëngjes, falas në the daily diff dot dev, linku më poshtë.

A do ta dërgoja një buton rishfaqjeje me këtë kontratë?

2:39 Vendimi, nën kapuç. Dërgojeni. Do të dërgoja çelësa të qëndrueshëm me rishfaqje të kufizuara dhe pajtim, kështu që klientët marrin kafe pa financuar edukimin tuaj të sistemeve të shpërndara. Dhe ky është ndryshimi për sot. Jam Niko nga Axrisi. Bashkohuni me përgjegjësi.

Burimet

1. Idempotent requestsStripe Docs
2. Designing robust and predictable APIs with idempotencyStripe Engineering — Brandur Leach
3. Advanced error handlingStripe Docs
4. HTTP Semantics — RFC 9110 §9.2.2 Idempotent MethodsIETF / RFC Editor