आप सुसंगत error responses कैसे design करते हैं और validation errors कैसे report करते हैं?

Question

IT Interview Practice · Accepted Answer

एक अच्छा error response दो चीज़ें करता है: यह **सही HTTP status code** इस्तेमाल करता है (machine-readable संकेत), और यह एक **सुसंगत, structured body** लौटाता है जिस पर एक developer क्रिया कर सके। असंगत error आकार client-side दर्द के सबसे बड़े स्रोतों में से एक हैं।

## एक standard error format इस्तेमाल करें: RFC 7807 (problem+json)

RFC 7807 एक समर्पित media type के साथ एक standard "problem details" body परिभाषित करता है, ताकि आपके API में हर error एक जैसी दिखे:

```http
HTTP/1.1 404 Not Found
Content-Type: application/problem+json

{
  "type": "https://api.example.com/errors/not-found",
  "title": "Resource not found",
  "status": 404,
  "detail": "No user exists with id 999",
  "instance": "/users/999"
}
```

- `type` — error श्रेणी की पहचान करने वाला एक URI (docs तक dereferenceable)।
- `title` — एक छोटा, human-readable सारांश (प्रति `type` स्थिर)।
- `status` — HTTP status, सुविधा के लिए दोहराया गया।
- `detail` — *इस* घटना के लिए एक विशिष्ट व्याख्या।
- `instance` — यह किस request/resource पर हुआ।

## Validation errors: उन्हें एक साथ report करें

Form/field validation के लिए, `422` (या `400`) और **field errors का एक array** लौटाएँ ताकि client हर गलत field को एक ही बार में highlight कर सके — एक-एक करके नहीं:

```http
HTTP/1.1 422 Unprocessable Entity
Content-Type: application/problem+json

{
  "type": "https://api.example.com/errors/validation",
  "title": "Validation failed",
  "status": 422,
  "errors": [
    { "field": "email", "code": "invalid_format", "message": "must be a valid email" },
    { "field": "age",   "code": "out_of_range",   "message": "must be >= 18" }
  ]
}
```

## सिद्धांत

```text
✓ Same body shape for every error (one code path on the client)
✓ A stable machine-readable code (type/code) — clients branch on this, not on prose
✓ Human-readable message for developers/logs
✗ Never leak stack traces, SQL, or internal paths to clients
```

## यह क्यों महत्वपूर्ण है

Error design वह जगह है जहाँ APIs असली दुनिया में चुपचाप सफल या असफल होते हैं: happy path आसान है, पर consumers अपना अधिकांश debugging समय error path में बिताते हैं, और एक असंगत या अस्पष्ट error contract integration को दयनीय बना देता है। Interviewers इसका उपयोग दो चीज़ें जाँचने के लिए करते हैं। पहला, **status code साथ structured body मिलकर काम करते हुए** — status tooling और retries के लिए मोटा संकेत है, body कार्रवाई-योग्य विवरण ले जाती है — बजाय error अंदर वाले `200 OK` के anti-pattern के। दूसरा, एक **स्थिर, machine-readable error code** (RFC 7807 के `type` या एक `code` field के ज़रिए) ताकि clients `"insufficient_funds"` पर branch कर सकें बजाय एक अंग्रेज़ी message से string-match करने के जो फिर से लिखा या localize किया जा सकता है। सारी validation errors एक साथ लौटाना, और stack traces जैसे internal विवरण कभी लीक न करना, एक ऐसे जवाब को पूरा करता है जो दिखाता है कि आपने ऐसे APIs बनाए हैं जिन्हें दूसरी teams को वास्तव में consume करना पड़ा।

एक standard error format इस्तेमाल करें: RFC 7807 (problem+json)

Validation errors: उन्हें एक साथ report करें

सिद्धांत

यह क्यों महत्वपूर्ण है

संबंधित प्रश्न