શું સમય પૂરો થયેલી એ સબમિટે ખરેખર તમારું કામ સાચવ્યું?

બટન ફરે છે, ટૅબ ભૂલ બતાવે છે, અને દસ મિનિટ ભરવામાં ગાળેલું ફોર્મ ગાયબ છે. તમે જાણતા નથી કે કનેક્શન મરતાં પહેલાં લેખન પહોંચ્યું કે નહીં. આ અજાણતાને નિષ્ફળતા તરીકે ગણવાની રીતે જ ડુપ્લિકેટ ટિપ્પણીઓ, બમણા ઓર્ડર અને વારંવારના સપોર્ટ ટિકિટ બનતા હોય છે.

નિશ્ચિત ક્રમમાં પુનઃપ્રાપ્ત કરો: ટેક્સ્ટ રાખો, પરિણામ શોધો, અને ત્યાર પછી જ નક્કી કરો કે બીજી સબમિટ માન્ય છે કે નહીં.

ટેક્સ્ટ અને સમય-છાપ સાથે શરૂ કરો

બીજું કંઈપણ અડકતા પહેલાં પૃષ્ઠમાંથી સામગ્રી કૉપી કરો, જેમાં બ્રાઉઝર હજી ક્ષેત્રમાં રાખેલો કોઈપણ ડ્રાફ્ટનો સમાવેશ થાય છે. સમય, તમે જે પૃષ્ઠ પર હતા અને તમે જે ક્રિયા કરી તે લખો, કારણ કે આ ત્રણ વિગતો જ બાકીની તપાસને શક્ય બનાવે છે. જો ટૅબ હજી ખુલ્લી હોય, તો નેટવર્ક એન્ટ્રી વાંચ્યા સુધી તેને ખુલ્લી રાખો. ટેક્સ્ટ સાચવવાનો કોઈ ખર્ચ નથી, અને તે ગુમાવવાનો ખર્ચ આખું કામ છે.

પછી તમે ખરેખર નિરીક્ષણ કરી શકો તેવા બે પ્રકારના ભંગને અલગ કરો. વિનંતીની વચ્ચે તૂટી ગયેલું કનેક્શન અને ભૂલ સાથે જવાબ આપનાર સર્વર નેટવર્ક પેનલમાં જુદા દેખાય છે, અને ફક્ત બીજું જ એપની નિર્ણય વિશે કંઈક કહે છે.

એપની પોતાની દૃશ્યમાં પરિણામ શોધો

પરિણામ બતાવતું વાંચન દૃશ્ય ફરી લોડ કરો: ટિપ્પણી સૂચિ, ઓર્ડર ઇતિહાસ, ટિકિટ કતાર અથવા તમે સંપાદિત કરી રહ્યા હતા તે રેકોર્ડ. નવીનતમ એન્ટ્રીને બદલે ખાતું, ગંતવ્ય, સમય અને સામગ્રી પ્રમાણે મેળ કરો, કારણ કે બીજું કોઈ તમારા પછી લખી શકે છે. પૃષ્ઠભૂમિ કાર્ય માટે, કનેક્ટિવિટી પરીક્ષણ તરીકે નવી કામગીરી બનાવવાને બદલે હાલના સંદર્ભ અને તેની સ્થિતિ શોધો.

જો પરિણામ ત્યાં હોય, તો તમે પૂરું કર્યું અને ભૂલ લેખનની નહીં, જવાબના માર્ગની છે. જો ન હોય, તો એપે હજી તેને નિશ્ચિત ન કર્યું હોવાની શક્યતા રાખો: કતારમાં રહેલું કાર્ય, વિલંબિત વાંચન દૃશ્ય અથવા પાછળ રહેતી પ્રતિકૃતિ સફળ લેખનને થોડા સમય માટે છુપાવી શકે છે.

નિષ્કર્ષ પર આવતા પહેલાં તેને નિશ્ચિત બીજી નજર આપો, અને બંને તપાસનો સમય નોંધો. વીસ સેકન્ડના અંતરે બે તપાસ દસ મિનિટના અંતરે બે તપાસ કરતાં ઘણા નબળા પુરાવા છે.

નક્કી કરો કે બીજી સબમિટ સુરક્ષિત છે કે નહીં

જવાબ કામગીરી પર આધાર રાખે છે, તમારી ધીરજ પર નહીં. HTTP એવી પદ્ધતિઓને અલગ પાડે છે જે સમાન ઇચ્છિત અસર સાથે પુનરાવર્તિત થઈ શકે છે અને જે નહીં, અને બીજા પ્રકારના સ્વયંસંચાલિત પુનઃપ્રયાસ સામે સલાહ આપે છે, સિવાય કે અર્થશાસ્ત્ર તેને મંજૂરી આપતું જાણીતું હોય. ટિપ્પણી બનાવવી, ઓર્ડર આપવો અને ચુકવણી મોકલવી સામાન્ય રીતે બીજા જૂથમાં આવે છે, તેથી સફળ દેખાતું બીજું ક્લિક પ્રથમ વિશે કંઈ કહેતું નથી.

જો તમે ક્લાયન્ટ જાળવો છો, તો API જે પુનઃપ્રયાસ અથવા આઇડેમ્પોટેન્સી પદ્ધતિનું દસ્તાવેજીકરણ કરે છે તે વાપરો, અને દરેક પ્રયાસ માટે નવી કી બનાવવાને બદલે તેને એ જ તાર્કિક કામગીરી સાથે જોડો. ટ્રેસિંગ માટે વપરાતો વિનંતી ઓળખકર્તા ડુપ્લિકેટ દબાવવાની કી નથી, સિવાય કે સર્વર તેને એવી ગણે.

curl -i -X POST https://api.example.net/v1/orders \
  -H "Idempotency-Key: 6f1c2a94-3b7e-4a10-9c22-5d0e8f7b1a63" \
  -H "Content-Type: application/json" \
  --data @order.json

કી ફક્ત ત્યારે જ મદદ કરે છે જ્યારે સેવા તેને કામગીરી સાથે સંગ્રહે અને પુનરાવર્તન પર મૂળ પરિણામ પાછું આપે. ઉત્પાદનમાં તેના પર આધાર રાખતા પહેલાં સ્ટેજિંગ એન્ડપોઇન્ટ પર તે વર્તન ચકાસો.

ફરી કંઈપણ દબાવતા પહેલાં પુરાવા એકત્ર કરો

ભૂલના સ્ક્રીનશોટને બદલે નેટવર્ક એન્ટ્રી રાખો. વિનંતીની પદ્ધતિ, URL, જવાબ અથવા સમયસીમા અને તે ક્યારે બન્યું તે જ એ છે જે વ્યવસ્થાપક એપના રેકોર્ડ સાથે સહસંબંધિત કરી શકે. એન્ટ્રીને આદેશ તરીકે નિકાસ કે કૉપી કરો, જો પછી તમે નકલમાંથી કૂકીઝ, ઑથોરાઇઝેશન હેડર અને કોઈપણ ખાનગી સામગ્રી દૂર કરો. તમારું પોતાનું સત્ર અકબંધ રાખો, અને પકડેલી ઓળખપત્રો ધરાવતી વિનંતીને ક્યારેય શૉર્ટકટ તરીકે ફરી ન ચલાવો.

સેવાના માલિકને એક ચોક્કસ પ્રશ્ન પૂછો: આ સામગ્રી સાથે આ સમયે કામગીરી સફળ થઈ, અને તેનો કોઈ સંદર્ભ છે? આ પ્રશ્નનો જવાબ છે, જ્યારે "સાઇટ તૂટી ગઈ" નો જવાબ નથી.

આ કવાયતનો હેતુ એ સ્થાપિત કરવો છે કે ક્રિયા બરાબર એક જ વાર થઈ. જે ભૂલસંદેશ તમે કાઢી શકો તે જે રેકોર્ડ પર તમે ભરોસો કરી શકો તેના સમાન નથી, અને બીજું જ તમને બીજું કંઈપણ મોકલતાં પહેલાં જોઈએ છે.