როგორ ააგებ თანმიმდევრულ error response-ებს და აცნობებ validation-ის შეცდომებს?

Question

IT Interview Practice · Accepted Answer

კარგი error response ორ რამეს აკეთებს: ის იყენებს **სწორ HTTP status code-ს** (მანქანით წაკითხვადი სიგნალი) და აბრუნებს **თანმიმდევრულ, სტრუქტურირებულ body-ს**, რომელზეც დეველოპერს შეუძლია მოქმედება. არათანმიმდევრული error ფორმები client-ის მხარეს ტკივილის ერთ-ერთი უდიდესი წყაროა.

## გამოიყენეთ სტანდარტული error ფორმატი: RFC 7807 (problem+json)

RFC 7807 განსაზღვრავს სტანდარტულ „problem details" body-ს გამოყოფილი media type-ით, ასე რომ ყოველი error თქვენს API-ში ერთნაირად გამოიყურება:

```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` — URI, რომელიც error-ის კატეგორიას აიდენტიფიცირებს (docs-მდე dereference-ადი).
- `title` — მოკლე, ადამიანით წაკითხვადი შეჯამება (სტაბილური თითო `type`-ზე).
- `status` — HTTP status, გამეორებული მოხერხებულობისთვის.
- `detail` — კონკრეტული ახსნა *ამ* შემთხვევისთვის.
- `instance` — რომელ request/resource-ზე მოხდა ის.

## Validation-ის შეცდომები: აცნობეთ ისინი ერთდროულად

form/field validation-ისთვის დააბრუნეთ `422` (ან `400`) და **field შეცდომების მასივი**, რომ client-მა ერთ გავლაზე მონიშნოს ყოველი ცუდი ველი — არა თითო შეცდომა ცალ-ცალკე:

```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 ადვილია, მაგრამ მომხმარებლები debug-ის დროის უმეტესობას error path-ში ხარჯავენ, და არათანმიმდევრული ან ბუნდოვანი error კონტრაქტი ინტეგრაციას სავალალოს ხდის. ინტერვიუერები ამას ორი რამის შესამოწმებლად იყენებენ. პირველი, **status code-ისა და სტრუქტურირებული body-ის ერთად მუშაობა** — status არის უხეში სიგნალი tooling-ისა და retry-ისთვის, body ატარებს ქმედითუნარიან დეტალს — და არა `200 OK`-ის anti-pattern error-ით შიგნით. მეორე, **სტაბილური, მანქანით წაკითხვადი error code** (RFC 7807-ის `type`-ის ან `code` ველის მეშვეობით), რომ client-მა `"insufficient_funds"`-ზე გაიყოს და არა ინგლისური message-ის სტრიქონულ დამთხვევაზე, რომელიც შეიძლება გადაიწეროს ან ლოკალიზდეს. ყველა validation შეცდომის ერთდროულად დაბრუნება და შიდა დეტალების, როგორიცაა stack trace, ვერასდროს გაჟონვა ასრულებს პასუხს, რომელიც აჩვენებს, რომ თქვენ ააშენეთ API-ები, რომლებიც სხვა გუნდებს რეალურად უნდა გამოეყენებინათ.

გამოიყენეთ სტანდარტული error ფორმატი: RFC 7807 (problem+json)

Validation-ის შეცდომები: აცნობეთ ისინი ერთდროულად

პრინციპები

რატომ არის ეს მნიშვნელოვანი

დაკავშირებული კითხვები