Si i projekton error responses koherente dhe si i raporton gabimet e validimit?

Question

IT Interview Practice · Accepted Answer

Një error response i mirë bën dy gjëra: përdor **HTTP status code-in e duhur** (sinjalin e lexueshëm nga makina), dhe kthen një **body koherent e të strukturuar** mbi të cilin një zhvillues mund të veprojë. Format jokoherente të error-eve janë një nga burimet më të mëdha të dhimbjes në anën e client-it.

## Përdor një format standard error-i: RFC 7807 (problem+json)

RFC 7807 përcakton një body standard "problem details" me një media type të dedikuar, kështu që çdo error në të gjithë API-n tënd duket i njëjtë:

```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` — një URI që identifikon kategorinë e error-it (i dereferencueshëm te docs).
- `title` — një përmbledhje e shkurtër, e lexueshme nga njeriu (e qëndrueshme për çdo `type`).
- `status` — HTTP status-i, i pasqyruar për lehtësi.
- `detail` — një shpjegim specifik për *këtë* rast.
- `instance` — te cili request/resource ndodhi.

## Gabimet e validimit: raportoji të gjitha njëherësh

Për validim form/field, kthe `422` (ose `400`) dhe një **varg gabimesh sipas fushës** që client-i të mund të theksojë çdo fushë të gabuar në një kalim — jo një gabim në një kohë:

```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" }
  ]
}
```

## Parimet

```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
```

## Pse ka rëndësi

Dizajni i error-eve është vendi ku API-t në heshtje kanë sukses ose dështojnë në botën reale: happy path është i lehtë, por konsumatorët e kalojnë pjesën më të madhe të kohës së debug-imit në rrugën e error-eve, dhe një kontratë error-esh jokoherente ose e paqartë e bën integrimin të mjerueshëm. Intervistuesit e përdorin këtë për të kontrolluar dy gjëra. Së pari, **status code plus body i strukturuar që punojnë së bashku** — status-i është sinjali i trashë për tooling dhe retry, body-ja mbart detajin e veprueshëm — sesa anti-modeli i `200 OK` me një error brenda. Së dyti, një **error code i qëndrueshëm e i lexueshëm nga makina** (përmes `type` të RFC 7807 ose një fushe `code`) që client-ët të mund të degëzojnë sipas `"insufficient_funds"` sesa të bëjnë string-match mbi një mesazh anglisht që mund të riformulohet ose lokalizohet. Kthimi i të gjitha gabimeve të validimit njëherësh, dhe mos-rrjedhja kurrë e detajeve të brendshme si stack traces, e plotëson një përgjigje që tregon se ke ndërtuar API që ekipe të tjera vërtet duhej t'i konsumonin.

Përdor një format standard error-i: RFC 7807 (problem+json)

Gabimet e validimit: raportoji të gjitha njëherësh

Parimet

Pse ka rëndësi

Pyetje të ngjashme