آپ مستقل error responses کیسے ڈیزائن کرتے ہیں اور validation errors کیسے رپورٹ کرتے ہیں؟

Question

IT Interview Practice · Accepted Answer

ایک اچھا error response دو کام کرتا ہے: یہ **درست HTTP status code** استعمال کرتا ہے (مشین کے پڑھنے کے قابل اشارہ)، اور ایک **مستقل، ساخت والا body** واپس کرتا ہے جس پر کوئی ڈویلپر عمل کر سکے۔ غیر مستقل error شکلیں client کی طرف تکلیف کے سب سے بڑے ذرائع میں سے ایک ہیں۔

## ایک معیاری 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، سہولت کے لیے دہرایا گیا۔
- `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 ڈیزائن وہ جگہ ہے جہاں APIs حقیقی دنیا میں خاموشی سے کامیاب یا ناکام ہوتی ہیں: happy path آسان ہے، لیکن صارفین اپنا زیادہ تر ڈیبگنگ وقت error path میں گزارتے ہیں، اور ایک غیر مستقل یا مبہم error معاہدہ انضمام (integration) کو دکھی بنا دیتا ہے۔ انٹرویو لینے والے اسے دو چیزیں جانچنے کے لیے استعمال کرتے ہیں۔ پہلی، **status code اور ساخت والا body مل کر کام کرتے ہیں** — status، tooling اور retries کے لیے کھردرا اشارہ ہے، body قابلِ عمل تفصیل اٹھاتا ہے — نہ کہ `200 OK` کے ساتھ اندر error والا anti-pattern۔ دوسری، ایک **مستحکم، مشین کے پڑھنے کے قابل error code** (RFC 7807 کے `type` یا ایک `code` field کے ذریعے) تاکہ clients کسی انگریزی message سے string ملانے کے بجائے، جسے دوبارہ لکھا یا مقامی (localize) کیا جا سکتا ہے، `"insufficient_funds"` پر شاخ بنا سکیں۔ تمام validation errors ایک ساتھ واپس کرنا، اور stack traces جیسی اندرونی تفصیلات کبھی لیک نہ کرنا، ایک ایسے جواب کو مکمل کرتا ہے جو ظاہر کرتا ہے کہ آپ نے ایسی APIs بنائی ہیں جنہیں دوسری ٹیموں کو واقعی استعمال کرنا پڑا۔

ایک معیاری error format استعمال کریں: RFC 7807 (problem+json)

Validation errors: سب ایک ساتھ رپورٹ کریں

اصول

یہ کیوں اہم ہے

متعلقہ سوالات