HTTP स्टेटस कोड समझें

सार: स्टेटस कोड या हेडर के छह defects (R1, R2, R4, R6, R7, R8), तीन सही रिस्पॉन्स (R3, R5, R9), और gateway के दो कोड जो सही हैं पर अपने पीछे की समस्या की ओर इशारा करते हैं (R10 जाँच के लिए, R11 एक defect)। नीचे हर row का विवरण है; हर expected result conventions से लिया गया है।

R1 — defect (C1)। Expected result: 201 Created और Location: /api/v2/orders/58213। 200 सिर्फ़ इतना कहता है कि "काम हो गया"; यह नहीं बताता कि नया रिसोर्स बना है, और जो क्लाइंट 201 जाँचता है, या नया order खोलने के लिए Location हेडर पढ़ता है, वह इस रिस्पॉन्स पर भरोसा नहीं कर सकता।

R2 — defect (C2)। बॉडी parse हो जाती है और 0 "कम से कम 1" का नियम तोड़ता है, इसलिए expected result 422 है, ऐसे JSON एरर के साथ जो फ़ील्ड quantity का नाम ले। 500 failure है; उसके पीछे का defect गायब वैलिडेशन है: value ऐसे code तक पहुँच गई जो उसे संभाल नहीं सका, और ख़राब इनपुट का सही जवाब कभी 500 नहीं होता। 0 और 1 इस नियम की दो boundary values हैं, इसलिए जाँचें कि 1 स्वीकार होता है, और -1, 1.5, "two" और गायब quantity भी आज़माएँ, ताकि पता चले कि गायब वैलिडेशन कितनी दूर तक फैला है।

R3 — सही (C2)। जो बॉडी parse ही न हो सके, उस पर JSON एरर बॉडी के साथ 400 आता है। यहाँ 422 गलत होता, क्योंकि वैलिडेट करने के लिए कुछ पढ़ा ही नहीं जा सका।

R4 — defect (C3)। टोकन न होने का मतलब "ऑथेंटिकेटेड नहीं" है: expected result 401 Unauthorized और WWW-Authenticate: Bearer, और RFC 9110 हर 401 पर यह हेडर ज़रूरी बताता है। 403 ऐप से कहता है "आप लॉग इन हैं पर अनुमति नहीं", इसलिए ऐप ग्राहक को sign-in स्क्रीन पर भेजने की जगह permission एरर दिखाता है। Expire हो चुके टोकन से भी दोबारा टेस्ट करें, क्योंकि C3 दोनों हालात कवर करती है, और एक जाँच रखें कि 403 अब भी अपनी सही जगह आता है: वैध टोकन से ऐसा action जिसकी उसे अनुमति नहीं।

R5 — सही (C4)। Order मौजूद है पर ग्राहक B का है। टीम ने 404 चुना ताकि API यह न बताए कि कौन-से order numbers मौजूद हैं, और गाइड 404 का यह इस्तेमाल बताती है (सर्वर बताना नहीं चाहता कि रिसोर्स मौजूद है)। यहाँ 403 आता तो वह C4 के ख़िलाफ़ defect होता, क्योंकि वह पुष्टि कर देता कि order 58101 मौजूद है। असली जाँच तुलना है: स्टेटस, हेडर और बॉडी अनजान order 99999999 के रिस्पॉन्स से बिल्कुल मेल खाने चाहिए, और खाते हैं।

R6 — defect (C5 और C8)। Expected result: JSON एरर बॉडी के साथ 409 Conflict, क्योंकि cancel करना order की मौजूदा state (पहले ही shipped) से टकराता है। "status":"error" के साथ 200 फ़ेलियर को छिपा देता है: ऐप ग्राहक को बता सकता है कि order cancel हो गया, और मॉनिटरिंग इस call को सफलता गिनती है। Side effects भी जाँचें: order अब भी shipped रहना चाहिए और कोई refund शुरू नहीं होना चाहिए।

R7 — defect (C6)। 61वीं रिक्वेस्ट पर 429 सही कोड है, लेकिन C6 जो Retry-After हेडर माँगती है वह गायब है, इसलिए ऐप नहीं जान सकता कि दोबारा कब कोशिश करे: या तो और रिक्वेस्ट भेजता है जिन पर 429 मिलता है, या ज़रूरत से ज़्यादा इंतज़ार करता है। Boundary भी जाँचें: उसी मिनट की 60वीं रिक्वेस्ट सफल होनी चाहिए।

R8 — defect (C7)। Expected result: 308 Permanent Redirect और Location: /api/v2/orders। 301 पर क्लाइंट POST को GET में बदल सकता है (RFC 9110 ऐतिहासिक कारणों से इसकी अनुमति देता है), और ठीक यही हुआ: basket कभी /v2 तक नहीं पहुँचा, कोई order नहीं बना, और chain का आख़िरी रिस्पॉन्स 200 है, इसलिए ऐप सफलता दिखा सकता है। गाइड की सलाह है कि API के लिए 301 की जगह 308 चुनें। पूछें कि ऐप के कौन-से versions अब भी /v1 call करते हैं: इसका जवाब तय करता है कि मामला कितना urgent है।

R9 — सही। 304 एरर नहीं है: ऐप ने ETag "a7f3" के साथ order कैश किया था और तब से वह बदला नहीं, इसलिए सर्वर ने बॉडी नहीं भेजी और ऐप अपनी कैश कॉपी दिखाता है। उल्टा case भी टेस्ट करें: order बदलने के बाद (जैसे cancel होने पर) वही रिक्वेस्ट नई बॉडी और नए ETag के साथ 200 लौटाए; वरना ग्राहक पुराना status देखते रहेंगे।

R10 — स्टेटस कोड में defect नहीं, जाँच के लिए एक सवाल। 502 का मतलब है लोड बैलेंसर को एप्लिकेशन से अवैध रिस्पॉन्स मिला या कोई रिस्पॉन्स नहीं मिला, जो 14:02 के deployment के दौरान एप्लिकेशन सर्वर के रीस्टार्ट होने से मेल खाता है। समय, build और रिक्वेस्ट दर्ज करें, और deployment पूरा होने के बाद दोबारा टेस्ट करें। अगर 502 deployment के बाहर भी आए तो यह एप्लिकेशन के क्रैश होने या कनेक्शन तोड़ने की ओर इशारा करता है: एप्लिकेशन logs के साथ रिपोर्ट करें। टीम के लिए दो सवाल: क्या deployment में रीस्टार्ट से पहले लोड बैलेंसर को उस सर्वर पर रिक्वेस्ट भेजना बंद कर देना चाहिए, ताकि क्लाइंट को 502 दिखे ही नहीं? और क्या ऐप उस HTML एरर पेज को संभाल पाता है जहाँ C2 JSON बॉडी का वादा करती है?

R11 — 504 ख़ुद सही है: लोड बैलेंसर ने 30 सेकंड इंतज़ार किया और एप्लिकेशन ने समय पर जवाब नहीं दिया। Defect उसके पीछे है: लंबी history (2019 से 2026) पर search उन 30 सेकंड में पूरी नहीं होती जो gateway देता है। Date range छोटी करके पता करें कि लगभग कहाँ से failure शुरू होता है, response times दर्ज करें, और इसे performance defect के रूप में रिपोर्ट करें। Product owner से पूछें कि क्या date range की कोई अधिकतम सीमा है: अगर है, तो जिस range को API serve नहीं करेगा उसे timeout की जगह 422 (C2) से reject होना चाहिए। वही रिक्वेस्ट दोहराने से कुछ नहीं बदलेगा।

Developer का सवाल: अभी जैसा है, वैसा सुरक्षित नहीं। अपने-आप दोबारा कोशिश तभी करें जब दोनों बातें सच हों: कोड अस्थायी हो (502, 503, 504) और मेथड idempotent हो (GET, PUT, DELETE)। R2 को दो वजहों से नहीं दोहराना चाहिए। उसका 500 रिक्वेस्ट की वजह से आया है, इसलिए हर बार वही लौटता है। और POST idempotent नहीं है, जो बड़ा जोखिम है: अगर POST /v2/orders पर 502 या 504 आए तो हो सकता है रिस्पॉन्स खोने से पहले सर्वर order बना चुका हो, और अपने-आप दोहराने से दूसरा order बन सकता है। फ़ेल हुए POST के बाद ऐप दोबारा भेजने का विकल्प देने से पहले GET से orders की list जाँचे, और developers बताएँ कि API duplicate orders को कैसे रोकता है। R10 दोहराना सुरक्षित है (GET, अस्थायी कोड, बैकऑफ़ के साथ)। R11 भी GET है, लेकिन बहुत भारी रिक्वेस्ट दोहराने से सिर्फ़ load बढ़ता है और वह फिर timeout होती है, इसलिए कोशिशों की गिनती कम रखें और बैकऑफ़ इस्तेमाल करें। आख़िर में, 429 एक 4xx है जिसे दोहराया जा सकता है, पर सिर्फ़ Retry-After के समय के बाद, और यह R7 के अहम होने की एक और वजह है।

सबसे पहले R8 रिपोर्ट करें। Title का उदाहरण: "POST /v1/orders 308 की जगह 301 लौटाता है; क्लाइंट उसे GET के रूप में दोबारा भेजता है और कोई order नहीं बनता"। यह पहले इसलिए है कि जो भी ऐप अब भी /v1 call करता है, उसके ग्राहक बिना किसी एरर मैसेज के अपने orders खो देते हैं, और chain 200 पर ख़त्म होती है। फिर R6 (फ़ेल हुआ cancellation सफलता के रूप में दिखता है) और R4 (टोकन न होना permission की समस्या के रूप में दिखता है, इसलिए ऐप ग्राहक को sign-in पर नहीं भेजता)। अगर आपने R6 को पहले रखा क्योंकि आप जानते हैं कि सभी ऐप /v2 पर आ चुके हैं, तो यह ठीक कारण है; अहम यह है कि प्राथमिकता ग्राहकों पर असर से तय हो। Fixes के बाद यही rows confirmation testing के रूप में दोबारा चलाएँ।

अपना काम जाँचने के लिए: हर row के लिए अपेक्षित कोड होना चाहिए, और जहाँ conventions माँगती हैं वहाँ हेडर भी (Location, WWW-Authenticate, Retry-After)। अगर आपने R3, R5 या R9 को defect माना, तो गाइड में फिर पढ़ें कि वह 400 बनाम 422 के बारे में, 404 के बारे में (सर्वर शायद न बताना चाहे कि रिसोर्स मौजूद है) और 304 के बारे में (एरर नहीं) क्या कहती है।