స్థిరమైన error responseలను ఎలా డిజైన్ చేసి validation errorsను ఎలా నివేదిస్తారు?

Question

IT Interview Practice · Accepted Answer

ఒక మంచి error response రెండు పనులు చేస్తుంది: **సరైన HTTP status code** (machine-readable సంకేతం)ను వాడుతుంది, మరియు ఒక developer చర్య తీసుకోగల **స్థిరమైన, నిర్మాణాత్మక body**ను తిరిగి ఇస్తుంది. అస్థిరమైన error ఆకృతులు client-వైపు బాధకు అతిపెద్ద మూలాలలో ఒకటి.

## ఒక 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: వాటన్నింటినీ ఒకేసారి నివేదించండి

form/field validation కోసం, `422` (లేదా `400`) మరియు ఒక **field errorsల array**ను తిరిగి ఇవ్వండి, తద్వారా client ఒక్క passలో ప్రతి చెడు 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 డిజైన్ అనేది APIలు నిజ ప్రపంచంలో నిశ్శబ్దంగా విజయవంతం లేదా విఫలమయ్యే చోటు: happy path సులభం, కానీ vinియోగదారులు తమ debugging సమయంలో ఎక్కువ భాగం error pathలో గడుపుతారు, మరియు ఒక అస్థిర లేదా అస్పష్ట error ఒప్పందం integrationను దుర్భరంగా చేస్తుంది. ఇంటర్వ్యూయర్‌లు దీన్ని రెండు విషయాల కోసం వాడతారు. మొదటిది, **status code మరియు నిర్మాణాత్మక body కలిసి పనిచేయడం** — status అనేది tooling మరియు retryల కోసం స్థూల సంకేతం, body చర్య తీసుకోదగిన వివరాన్ని మోస్తుంది — లోపల error ఉన్న `200 OK` అనే anti-pattern కాదు. రెండవది, ఒక **స్థిరమైన, machine-readable error code** (RFC 7807 యొక్క `type` లేదా ఒక `code` field ద్వారా), తద్వారా clientలు తిరిగి-వ్రాయబడగల లేదా localize చేయబడగల ఒక ఇంగ్లీష్ messageను string-match చేయడం బదులు `"insufficient_funds"` మీద branch చేయగలవు. అన్ని validation errorsను ఒకేసారి తిరిగి ఇవ్వడం, stack traces వంటి అంతర్గత వివరాలను ఎప్పుడూ leak చేయకపోవడం — ఇతర జట్లు నిజంగా వాడాల్సిన APIలను మీరు నిర్మించారని చూపే జవాబును పూర్తి చేస్తుంది.

ఒక standard error format వాడండి: RFC 7807 (problem+json)

Validation errors: వాటన్నింటినీ ఒకేసారి నివేదించండి

సూత్రాలు

ఇది ఎందుకు ముఖ్యం

సంబంధిత ప్రశ్నలు