સુસંગત error responses કેવી રીતે design કરો છો અને validation errors કેવી રીતે જણાવો છો?

Question

IT Interview Practice · Accepted Answer

સારો error response બે વસ્તુ કરે છે: તે **યોગ્ય HTTP status code** (machine-readable સંકેત) વાપરે છે, અને એક **સુસંગત, structured body** પરત કરે છે જેના પર developer કાર્ય કરી શકે. અસંગત error આકારો client-side પીડાના સૌથી મોટા સ્રોતોમાંનો એક છે.

## પ્રમાણભૂત error format વાપરો: RFC 7807 (problem+json)

RFC 7807 એક સમર્પિત media type સાથે પ્રમાણભૂત "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, સગવડ માટે mirror કરેલ.
- `detail` — *આ* ઘટના માટે ચોક્કસ સમજૂતી.
- `instance` — તે કયા request/resource પર થયું.

## Validation errors: તે બધા એકસાથે જણાવો

form/field validation માટે, `422` (કે `400`) અને **field errors ની array** પરત કરો જેથી client એક જ pass માં દરેક ખરાબ field ને highlight કરી શકે — એક સમયે એક 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
✓ દરેક error માટે એ જ body આકાર (client પર એક code path)
✓ સ્થિર machine-readable code (type/code) — clients આના પર branch કરે છે, prose પર નહીં
✓ developers/logs માટે માનવ-વાંચનીય message
✗ clients ને ક્યારેય stack traces, SQL, કે internal paths leak ન કરો
```

## આ શા માટે મહત્વનું છે

Error design એ છે જ્યાં APIs વાસ્તવિક દુનિયામાં ચૂપચાપ સફળ કે નિષ્ફળ થાય છે: happy path સરળ છે, પણ consumers તેમનો મોટા ભાગનો debugging સમય error path માં ગાળે છે, અને અસંગત કે અસ્પષ્ટ error contract integration ને દયનીય બનાવે છે. Interviewers આનો ઉપયોગ બે વસ્તુ તપાસવા કરે છે. પ્રથમ, **status code વત્તા structured body સાથે મળીને કામ કરે છે** — status એ tooling અને retries માટે સ્થૂળ સંકેત છે, body actionable વિગત વહન કરે છે — અંદર error સાથે `200 OK` ના anti-pattern ને બદલે. બીજું, એક **સ્થિર, machine-readable error code** (RFC 7807 ના `type` કે `code` field દ્વારા) જેથી clients ફરી લખાયેલ કે localized થઈ શકે તેવા English message ને string-match કરવાને બદલે `"insufficient_funds"` પર branch કરી શકે. બધા validation errors એકસાથે પરત કરવા, અને stack traces જેવી internal વિગતો ક્યારેય leak ન કરવી, એવો જવાબ પૂરો કરે છે જે દર્શાવે છે કે તમે એવા APIs બનાવ્યા છે જે અન્ય teams ને ખરેખર વાપરવા પડ્યા.

પ્રમાણભૂત error format વાપરો: RFC 7807 (problem+json)

Validation errors: તે બધા એકસાથે જણાવો

સિદ્ધાંતો

આ શા માટે મહત્વનું છે

સંબંધિત પ્રશ્નો