சீரான error responses-ஐ எப்படி design செய்வது மற்றும் validation errors-ஐ எப்படி அறிக்கை செய்வது?

Question

IT Interview Practice · Accepted Answer

ஒரு நல்ல error response இரண்டு காரியங்களைச் செய்கிறது: அது **சரியான HTTP status code**-ஐப் பயன்படுத்துகிறது (machine-readable சமிக்ஞை), மற்றும் ஒரு developer செயல்பட முடியும் ஒரு **சீரான, கட்டமைக்கப்பட்ட body**-ஐத் திருப்புகிறது. சீரற்ற error shapes 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` — ஒரு குறுகிய, human-readable சுருக்கம் (ஒவ்வொரு `type`-க்கும் நிலையானது).
- `status` — HTTP status, வசதிக்காக பிரதிபலிக்கப்பட்டது.
- `detail` — *இந்த* நிகழ்வுக்கான ஒரு குறிப்பிட்ட விளக்கம்.
- `instance` — அது எந்த request/resource-இல் நடந்தது.

## Validation errors: அனைத்தையும் ஒரே நேரத்தில் அறிக்கை செய்யவும்

Form/field validation-க்கு, `422` (அல்லது `400`) மற்றும் ஒரு **field errors array**-ஐத் திருப்பவும், client ஒவ்வொரு தவறான 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
✓ 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 எளிது, ஆனால் நுகர்வோர் தங்கள் debugging நேரத்தில் பெரும்பாலானதை error path-இல் செலவழிக்கிறார்கள், மேலும் ஒரு சீரற்ற அல்லது தெளிவற்ற error contract integration-ஐ துயரமாக்குகிறது. Interviewers இரண்டு விஷயங்களைச் சரிபார்க்க இதைப் பயன்படுத்துகிறார்கள். முதலில், **status code மற்றும் கட்டமைக்கப்பட்ட body ஒன்றாக வேலை செய்தல்** — status என்பது tooling மற்றும் retries-க்கான கரடுமுரடான சமிக்ஞை, 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 போன்ற internal விவரங்களை ஒருபோதும் கசியவிடாதது, மற்ற teams உண்மையில் நுகர வேண்டியிருந்த APIs-ஐ நீங்கள் கட்டியிருக்கிறீர்கள் என்பதைக் காட்டும் ஒரு பதிலை முழுமையாக்குகிறது.

ஒரு standard error format பயன்படுத்தவும்: RFC 7807 (problem+json)

Validation errors: அனைத்தையும் ஒரே நேரத்தில் அறிக்கை செய்யவும்

கொள்கைகள்

இது ஏன் முக்கியம்

தொடர்புடைய கேள்விகள்