کیا وقت ختم ہونے والی اس جمع آوری نے واقعی آپ کا کام محفوظ کیا؟

بٹن گھوم رہا ہے، ٹیب خرابی دکھا رہا ہے، اور وہ فارم غائب ہے جو آپ نے دس منٹ میں بھرا۔ آپ نہیں جانتے کہ کنکشن ٹوٹنے سے پہلے تحریر پہنچی یا نہیں۔ اسی نامعلوم کو ناکامی سمجھنا ہی نقل شدہ تبصرے، دوہرے آرڈر اور بار بار آنے والی معاونت کی ٹکٹیں پیدا کرتا ہے۔

مقررہ ترتیب میں بحال کریں: متن رکھیں، نتیجہ تلاش کریں، اور اسی کے بعد فیصلہ کریں کہ دوسری جمع آوری کی اجازت ہے یا نہیں۔

متن اور وقت کی مُہر سے شروع کریں

کسی اور چیز کو چھونے سے پہلے صفحے سے مواد نقل کریں، اس مسودے سمیت جو براؤزر ابھی خانے میں رکھے ہوئے ہے۔ وقت، وہ صفحہ جس پر آپ تھے اور وہ عمل جو آپ نے کیا لکھ لیں، کیونکہ یہی تین تفصیلات باقی تفتیش کو ممکن بناتی ہیں۔ اگر ٹیب ابھی کھلا ہے تو نیٹ ورک اندراج پڑھنے تک اسے کھلا رہنے دیں۔ متن محفوظ کرنے کا کوئی خرچ نہیں، اور اسے کھو دینے کا خرچ پورا کام ہے۔

پھر ان دو قسم کی خرابیوں کو الگ کریں جنہیں آپ واقعی دیکھ سکتے ہیں۔ درخواست کے بیچ میں ٹوٹا ہوا کنکشن اور خرابی کے ساتھ جواب دینے والا سرور نیٹ ورک پینل میں مختلف دکھتے ہیں، اور ایپ کے فیصلے کے بارے میں کچھ صرف دوسرا ہی بتاتا ہے۔

ایپ کے اپنے منظر میں نتیجہ تلاش کریں

وہ پڑھنے کا منظر دوبارہ لوڈ کریں جو نتیجہ دکھائے گا: تبصروں کی فہرست، آرڈر کی تاریخ، ٹکٹ کی قطار یا وہ ریکارڈ جس میں آپ ترمیم کر رہے تھے۔ تازہ ترین اندراج کے بجائے اکاؤنٹ، منزل، وقت اور مواد کے مطابق ملائیں، کیونکہ آپ کے بعد کوئی اور لکھ سکتا ہے۔ پس منظر کے کام کے لیے، کنیکٹیویٹی جانچ کے طور پر نیا عمل بنانے کے بجائے موجودہ حوالہ اور اس کی حالت تلاش کریں۔

اگر نتیجہ وہاں ہے تو آپ مکمل کر چکے اور خرابی تحریر کی نہیں، جواب کے راستے کی ہے۔ اگر نہیں ہے تو یہ امکان رکھیں کہ ایپ نے اسے ابھی طے نہیں کیا: قطار میں موجود کام، تاخیر سے آنے والا پڑھنے کا منظر یا پیچھے رہ جانے والی نقل کامیاب تحریر کو کچھ دیر چھپا سکتی ہے۔

نتیجہ اخذ کرنے سے پہلے اسے مقررہ دوسری نظر دیں، اور دونوں جانچوں کا وقت لکھیں۔ بیس سیکنڈ کے وقفے سے کی گئی دو جانچیں دس منٹ کے وقفے سے کی گئی دو جانچوں سے بہت کمزور ثبوت ہیں۔

فیصلہ کریں کہ دوسری جمع آوری محفوظ ہے یا نہیں

جواب عمل پر منحصر ہے، آپ کے صبر پر نہیں۔ 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، جواب یا وقت کی حد اور یہ کب ہوا، یہی وہ چیزیں ہیں جو منتظم ایپ کے ریکارڈ سے ملا سکتا ہے۔ اندراج کو بطور کمانڈ برآمد یا نقل کریں، صرف اسی صورت میں جب بعد میں نقل سے کوکیز، اجازت کے ہیڈر اور کوئی بھی نجی مواد ہٹا دیں۔ اپنا سیشن برقرار رکھیں، اور پکڑی گئی اسناد والی درخواست کو کبھی شارٹ کٹ کے طور پر دوبارہ نہ چلائیں۔

سروس کے مالک سے ایک واضح سوال پوچھیں: کیا اس مواد کے ساتھ اس وقت عمل کامیاب ہوا، اور کیا اس کا کوئی حوالہ ہے؟ اس سوال کا جواب ہے، جبکہ "کیا سائٹ خراب ہوئی" کا جواب نہیں ہے۔

اس مشق کا مقصد یہ ثابت کرنا ہے کہ عمل بالکل ایک بار ہوا۔ جس خرابی کے پیغام کو آپ بند کر سکتے ہیں وہ اس ریکارڈ کے برابر نہیں جس پر آپ بھروسہ کر سکتے ہیں، اور کچھ اور بھیجنے سے پہلے آپ کو دوسرا ہی درکار ہے۔