मानक एरर रिस्पॉन्स

हर विफलता के लिए एक आकार

जो भी गलत हो — वैलिडेशन, ऑथ, सर्वर क्रैश — एरर बॉडी की संरचना एक जैसी होनी चाहिए, ताकि क्लाइंट हर एंडपॉइंट के लिए अलग के बजाय एक एरर-हैंडलिंग पाथ लिख सके।

पुन: उपयोग योग्य लिफ़ाफ़ा

एक मशीन-पठनीय code, एक इंसानी message, और फ़ील्ड-स्तरीय समस्याओं के लिए वैकल्पिक details।

HTTP/1.1 422 Unprocessable Entity

{
  "error": {
    "code": "VALIDATION_FAILED",
    "message": "Request has invalid fields.",
    "details": [
      { "field": "email", "issue": "must be a valid email address" }
    ]
  }
}

मशीन के लिए कोड, इंसान के लिए संदेश

क्लाइंट को error.code (एक स्थिर स्ट्रिंग) पर शाखा लेनी चाहिए, error.message पार्स करके कभी नहीं — मैसेज टेक्स्ट बिना चेतावनी के शब्द बदल सकता है, इससे जुड़ा कोई भी लॉजिक टूट जाएगा।

आंतरिक जानकारी लीक न करें

क्लाइंट-सामना करने वाले एरर में कभी स्टैक ट्रेस, SQL क्वेरी या फ़ाइल पाथ न डालें — इन्हें सर्वर-साइड पर requestId के साथ लॉग करें, और सपोर्ट के ट्रेस करने के लिए क्लाइंट को केवल वह id लौटाएँ।