API में 401, 403, 429 या 503 त्रुटि आए तो कहाँ से शुरू करें

बदलाव से पहले त्रुटि की जानकारी लें

Method, endpoint, status, समय और उपलब्ध request ID लिखें। Error body तथा संबंधित response headers पढ़ें। यह भी पहचानें कि उत्तर API application, gateway या सुरक्षा proxy ने भेजा; इनके मना करने के कारण अलग हो सकते हैं।

एक न्यूनतम अनुरोध से समस्या दोहराएँ, लगातार retries से नहीं। सफल अनुरोध से तुलना करें और एक समय में एक चीज बदलें। Authorization, cookies या credentials वाले पूरे URL को screenshots और logs में न रखें। सहायता के लिए request ID साझा करना आम तौर पर बेहतर है।

दोहराने से पहले कारण जाँचें

401 के लिए क्रेडेंशियल और प्रमाणीकरण का तरीका देखें। 403 के लिए अनुमतियाँ और माँगा गया संसाधन जाँचें। उसी निषिद्ध अनुरोध को दोहराने से आम तौर पर परिणाम नहीं बदलता।

401 और 403 की अलग जाँच करें

401 पर देखें कि credential मौजूद है, समाप्त नहीं हुआ और सही scheme, जैसे Bearer, इस्तेमाल करता है। मानक के अनुसार 401 में WWW-Authenticate होता है। API समर्थित refresh दे तो एक बार refresh और एक बार retry करें। अनंत refresh गलत credential ठीक नहीं करता।

403 पर account role, संसाधन और API permissions देखें। उपयोगकर्ता पढ़ सकता है, लेकिन बदलने का अधिकार नहीं हो सकता। Proxy भी IP या क्षेत्र रोक सकता है। नया token बनाने से अनुपस्थित अधिकार नहीं मिलता; error body और सेवा के नियम पढ़ें।

दोबारा अनुरोध सीमित तरीके से भेजें

429 या 503 के साथ Retry-After मिले तो उसे देखें और सीमित प्रयासों के साथ प्रतीक्षा का समय बढ़ाएँ। कार्रवाई तभी दोहराएँ जब उसे दोहराना सुरक्षित हो; समय सीमा पार करने वाली लिखने की कार्रवाई पहले ही पूरी हो सकती है। समस्या की जाँच के लिए अनुरोध ID रखें और क्रेडेंशियल लॉग न करें।

Retry-After क्या कहता है

429 उपयोगकर्ता, IP या साझा quota की सीमा हो सकती है। नीचे के उदाहरण में Retry-After: 30 का अर्थ अगली कोशिश से पहले 30 सेकंड प्रतीक्षा है। यह header HTTP date भी हो सकता है; वास्तविक client दोनों रूप समझे।

Concurrency घटाएँ और एक quota वाले workers के retries समन्वित करें। 503 में सेवा और gateway का स्वास्थ्य भी देखें। Retry-After मानें; न हो तो random jitter सहित बढ़ते, सीमित अंतराल और कुल समय सीमा रखें। अधिक retries overload को लंबा कर सकती हैं।

HTTP/1.1 429 Too Many Requests
Retry-After: 30

उत्तर न मिलना, ऑपरेशन न होने का प्रमाण नहीं

भुगतान या job बनाने का अनुरोध server स्वीकार कर सकता है और उसके बाद timeout हो सकता है। पहला उत्तर न मिलने पर भी दोबारा भेजना duplicate बना सकता है। Writes के लिए API का documented idempotency तरीका अपनाएँ या फिर भेजने से पहले status देखें। असमर्थित idempotency header खुद न बनाएँ।

उपयोगी client स्थायी authorization समस्याओं और अस्थायी विफलताओं को अलग करता है, प्रयास सीमित रखता है और रुकने का कारण दर्ज करता है। GET दोहराना अक्सर POST से सरल है, लेकिन API contract निर्णायक है। समय, endpoint, status और request ID दें, secrets हटाकर।