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

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

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

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

एक मशीन-पठनीय 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" }
    ]
  }
}

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

Clients को error.code (स्थिर string) पर branch करना चाहिए, error.message parse करके कभी नहीं; message text बिना चेतावनी बदल सकता है। मानक Problem Details format (RFC 9457, application/problem+json) पर विचार करें।

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

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