सुसंगत error responses कसे design करता आणि validation errors कसे कळवता?

Question

IT Interview Practice · Accepted Answer

चांगला error response दोन गोष्टी करतो: तो **योग्य HTTP status code** वापरतो (machine-readable signal), आणि तो एक **सुसंगत, संरचित 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 पर्यंत dereference करता येण्याजोगे).
- `title` — एक लहान, माणसाला वाचता येणारा सारांश (प्रति `type` स्थिर).
- `status` — HTTP status, सोयीसाठी पुनरावृत्त.
- `detail` — *या* घटनेसाठीचे विशिष्ट स्पष्टीकरण.
- `instance` — ते कोणत्या request/resource वर घडले.

## Validation errors: सर्व एकाच वेळी कळवा

Form/field validation साठी, `422` (किंवा `400`) आणि **field errors चा array** परत करा जेणेकरून client प्रत्येक चुकीचे field एकाच फेरीत ठळक करू शकेल — एका वेळी एक error नव्हे:

```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 करार integration दु:खद करतो. Interviewers हे दोन गोष्टी तपासण्यासाठी वापरतात. पहिली, **status code आणि structured body एकत्र काम करणे** — status हे tooling आणि retries साठीचे स्थूल signal आहे, body कृती करण्याजोगा तपशील वाहते — आत error असलेल्या `200 OK` च्या anti-pattern ऐवजी. दुसरी, एक **स्थिर, machine-readable error code** (RFC 7807 च्या `type` किंवा `code` field मार्फत) जेणेकरून clients पुन्हा शब्दबद्ध किंवा localize होऊ शकणाऱ्या English message शी string-match करण्याऐवजी `"insufficient_funds"` वर branch करू शकतील. सर्व validation errors एकाच वेळी परत करणे, आणि stack traces सारखे अंतर्गत तपशील कधीही उघड न करणे, हे तुम्ही इतर teams ना प्रत्यक्षात वापराव्या लागलेल्या APIs बांधल्या हे दर्शवणारे उत्तर पूर्ण करते.

एक standard error format वापरा: RFC 7807 (problem+json)

Validation errors: सर्व एकाच वेळी कळवा

तत्त्वे

हे का महत्त्वाचे आहे

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