स्थिति, प्रकार और घटना अलग करें
RFC 9457 application/problem+json परिभाषित करता है। स्थिर समस्या प्रकार और घटना का समझने योग्य विवरण दें; निर्णय के लिए क्लाइंट से अनूदित वाक्य का विश्लेषण न कराएँ। status हो तो वास्तविक HTTP स्थिति से मेल रखें।
| स्थिति | HTTP अर्थ | संभावित कदम |
|---|---|---|
| 400 | गलत अनुरोध | दोबारा भेजने से पहले सुधारें। |
| 401 | वैध प्रमाणीकरण विवरण नहीं | विवरण और तय तरीका जाँचें। |
| 403 | अनुरोध समझा पर अस्वीकृत | अधिकार जाँचें; दोहराने से नहीं मिलते। |
| 503 | सेवा अस्थायी रूप से अनुपलब्ध | ऑपरेशन अनुमति दे तो सीमित प्रतीक्षा और प्रयास। |
विफलता के रास्ते स्पष्ट करें
- कोड, प्रारूप और अपेक्षित प्रतिक्रिया लिखें। खाली उत्तर, गेटवे का गैर-JSON, टूटा कनेक्शन और टाइमआउट भी जाँचें।
- सर्वर पर इनपुट और अधिकार जाँचें। अपेक्षित त्रुटियाँ संभालें, अज्ञात खराबी न छिपाएँ; व्यावसायिक विफलता को सफलता न दिखाएँ।
- सहायता के लिए सहसंबंध पहचान लौटाएँ। स्टैक ट्रेस, आंतरिक क्वेरी, पासवर्ड और टोकन सार्वजनिक उत्तर में न दें।
तभी दोहराएँ जब उचित हो
5xx असीमित प्रयासों की अनुमति नहीं है। अनुबंध, ऑपरेशन की स्थिति, इडेम्पोटेंसी और कुल समय मिलाकर निर्णय लें। न्यूनतम, संवेदनशील डेटा रहित उदाहरण से दोष बताएँ; सुधार के बाद मूल मामला और पास के पहुँच-निषेध जाँचें।
प्राथमिक स्रोत
API एरर को बिना लीकेज के एक्शन गाइड करना चाहिए।
HTTP स्टेटस एक शुरुआती कैटेगरी देता है, लेकिन क्लाइंट को एक स्टेबल टाइप और काम की डिटेल की ज़रूरत हो सकती है। RFC 9457 एक आम प्रॉब्लम स्ट्रक्चर बताता है; यह इंटरनल ट्रेस या सेंसिटिव डेटा को एक्सपोज़ करने को सही नहीं ठहराता है।
- परमानेंट इनकार, ठीक किया जा सकने वाला इनपुट और टेम्पररी फेलियर को अलग करें।
- हर ज़रूरी एरर के लिए डॉक्यूमेंट टाइप, स्टेटस और क्लाइंट का संभावित एक्शन।
- टेस्ट करें कि रिस्पॉन्स में कोई सीक्रेट या गैर-ज़रूरी फुल पेलोड नहीं हैं।
प्राथमिक स्रोत: IETF RFC 9457 — Problem Details for HTTP APIs. संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.
API दोहराव: पूरे समय का बजट गिनें
कॉल सीमा और कुल समय सीमा तय करें।
काल्पनिक शैक्षिक मामला: आँकड़े CIE या ग्राहकों के परिणाम नहीं हैं।
काल्पनिक मॉडल: चार कॉल, हर एक अधिकतम 250 मिलीसेकंड; प्रतीक्षा 100, 200, 400। जिटर, कनेक्शन, कतार और स्थानीय जाँच बाहर हैं।
- कुल प्रयास
- 41 + 3
- कुल प्रतीक्षा (ms)
- 700100 + 200 + 400
- मॉडल बजट (ms)
- 17004 × 250 + 700
| चरण | अधिकतम कॉल (ms) | अगली प्रतीक्षा (ms) |
|---|---|---|
| प्रयास 1 | 250 | 100 |
| प्रयास 2 | 250 | 200 |
| प्रयास 3 | 250 | 400 |
| प्रयास 4 | 250 | 0 |
| कुल | 1000 | 700 |
- कॉल समय1,000
- कुल प्रतीक्षा700
- कुल समय सीमा (ms)1,500
निष्कर्ष से पहले जाँच
- 1,000 + 700 = 1,700 समय सीमा 1,500 मिलीसेकंड से अधिक है।
- कुल समय सीमा आगे दें और दोहरे प्रभाव रोकें; टाइमआउट दूरस्थ रद्द होना सिद्ध नहीं करता।
पुनः प्रयास का बजट आज़माएँ
n × T + W × (2^(n−1) − 1)
संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.
API त्रुटियाँ: प्रकार, स्थिति और प्रमाण
इस संस्करण में विस्तृत संदर्भ टिप्पणियाँ अंग्रेज़ी में उपलब्ध हैं।
Handle an error without parsing its sentence
An API client may receive a translated title, missing member or unfamiliar extension. Preserve decisions based on the documented type and HTTP status, then connect a safe action to the context.
- Compare received status and JSON status without silently replacing either.
- Test absent type, string status instead of a number, and an unknown extension.
- Separate person-facing text, business code and occurrence reference.
Explore problem types and eight fictional responses →
IETF · M. Nottingham, E. Wilde, S. Dalal · RFC 9457 · July 2023 · obsoletes RFC 7807 · §3.1, §3.2, §4.2, §5