ਤੁਸੀਂ ਇੱਕਸਾਰ error responses ਕਿਵੇਂ design ਕਰਦੇ ਹੋ ਅਤੇ validation errors ਕਿਵੇਂ report ਕਰਦੇ ਹੋ?

Question

IT Interview Practice · Accepted Answer

ਇੱਕ ਵਧੀਆ error response ਦੋ ਕੰਮ ਕਰਦਾ ਹੈ: ਇਹ **ਸਹੀ HTTP status code** ਵਰਤਦਾ ਹੈ (ਮਸ਼ੀਨ-ਪੜ੍ਹਨਯੋਗ ਸੰਕੇਤ), ਅਤੇ ਇਹ ਇੱਕ **ਇੱਕਸਾਰ, ਸੰਰਚਿਤ 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 ਤੱਕ dereferenceable)।
- `title` — ਇੱਕ ਛੋਟਾ, ਮਨੁੱਖ-ਪੜ੍ਹਨਯੋਗ ਸਾਰ (ਹਰ `type` ਲਈ ਸਥਿਰ)।
- `status` — HTTP status, ਸਹੂਲਤ ਲਈ ਦੁਹਰਾਇਆ।
- `detail` — *ਇਸ* ਵਾਰ ਲਈ ਇੱਕ ਖ਼ਾਸ ਵਿਆਖਿਆ।
- `instance` — ਇਹ ਕਿਸ request/resource 'ਤੇ ਹੋਇਆ।

## Validation errors: ਸਭ ਇੱਕੋ ਵਾਰ report ਕਰੋ

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 ਆਸਾਨ ਹੈ, ਪਰ ਖਪਤਕਾਰ ਆਪਣਾ ਬਹੁਤਾ debugging ਸਮਾਂ error path ਵਿੱਚ ਬਿਤਾਉਂਦੇ ਹਨ, ਅਤੇ ਇੱਕ ਅਸੰਗਤ ਜਾਂ ਅਸਪਸ਼ਟ error ਇਕਰਾਰ integration ਨੂੰ ਦੁਖਦਾਈ ਬਣਾ ਦਿੰਦਾ ਹੈ। ਇੰਟਰਵਿਊ ਲੈਣ ਵਾਲੇ ਇਸਨੂੰ ਦੋ ਚੀਜ਼ਾਂ ਜਾਂਚਣ ਲਈ ਵਰਤਦੇ ਹਨ। ਪਹਿਲਾ, **status code ਅਤੇ ਸੰਰਚਿਤ body ਇਕੱਠੇ ਕੰਮ ਕਰਦੇ ਹੋਏ** — status tooling ਅਤੇ retries ਲਈ ਮੋਟਾ ਸੰਕੇਤ ਹੈ, body ਕਾਰਵਾਈਯੋਗ ਵੇਰਵਾ ਰੱਖਦਾ ਹੈ — ਨਾ ਕਿ ਅੰਦਰ error ਵਾਲੇ `200 OK` ਦਾ anti-pattern। ਦੂਜਾ, ਇੱਕ **ਸਥਿਰ, ਮਸ਼ੀਨ-ਪੜ੍ਹਨਯੋਗ error code** (RFC 7807 ਦੇ `type` ਜਾਂ ਇੱਕ `code` field ਰਾਹੀਂ) ਤਾਂ ਜੋ clients ਇੱਕ ਅੰਗਰੇਜ਼ੀ message ਨਾਲ string-match ਕਰਨ ਦੀ ਬਜਾਏ `"insufficient_funds"` 'ਤੇ branch ਕਰ ਸਕਣ, ਜੋ ਦੁਬਾਰਾ ਲਿਖਿਆ ਜਾਂ localized ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਸਾਰੇ validation errors ਇੱਕੋ ਵਾਰ ਵਾਪਸ ਕਰਨਾ, ਅਤੇ stack traces ਵਰਗੇ ਅੰਦਰੂਨੀ ਵੇਰਵੇ ਕਦੇ leak ਨਾ ਕਰਨਾ, ਇੱਕ ਅਜਿਹੇ ਜਵਾਬ ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ ਜੋ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਅਜਿਹੇ APIs ਬਣਾਏ ਹਨ ਜੋ ਹੋਰ teams ਨੂੰ ਅਸਲ ਵਿੱਚ ਵਰਤਣੇ ਪਏ।

ਇੱਕ ਮਿਆਰੀ error format ਵਰਤੋ: RFC 7807 (problem+json)

Validation errors: ਸਭ ਇੱਕੋ ਵਾਰ report ਕਰੋ

ਸਿਧਾਂਤ

ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

ਸੰਬੰਧਿਤ ਸਵਾਲ