# मानक एरर रिस्पॉन्स — REST API Design: Resources, Status Codes और Security

Source: https://www.skillbyai.com/hi/restapi/api-error-shape

> एक consistent error format लौटाएँ जिसमें स्थिर machine-readable codes हों, और clients को stack traces कभी न दिखाएँ।

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

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

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

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

```json
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 लौटाएँ।