Πώς σχεδιάζετε συνεπείς αποκρίσεις σφάλματος και αναφέρετε σφάλματα validation;

Question

IT Interview Practice · Accepted Answer

Μια καλή απόκριση σφάλματος κάνει δύο πράγματα: χρησιμοποιεί το **σωστό status code HTTP** (το σήμα που διαβάζεται από μηχανή), και επιστρέφει ένα **συνεπές, δομημένο body** πάνω στο οποίο ένας developer μπορεί να ενεργήσει. Τα ασυνεπή σχήματα σφαλμάτων είναι μία από τις μεγαλύτερες πηγές πόνου στην πλευρά του client.

## Χρησιμοποιήστε ένα τυπικό φορμά σφάλματος: RFC 7807 (problem+json)

Το RFC 7807 ορίζει ένα τυπικό body "problem details" με έναν ειδικό media type, ώστε κάθε σφάλμα σε όλο το 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 που ταυτοποιεί την κατηγορία σφάλματος (dereferenceable προς documentation).
- `title` — μια σύντομη, ανθρωπίνως αναγνώσιμη περίληψη (σταθερή ανά `type`).
- `status` — το status HTTP, αντιγραμμένο για ευκολία.
- `detail` — μια συγκεκριμένη εξήγηση για *αυτή* την εμφάνιση.
- `instance` — σε ποιο request/πόρο συνέβη.

## Σφάλματα validation: αναφέρετέ τα όλα μαζί

Για validation φόρμας/πεδίου, επιστρέψτε `422` (ή `400`) και έναν **πίνακα σφαλμάτων ανά πεδίο** ώστε ο 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
```

## Γιατί έχει σημασία

Ο σχεδιασμός σφαλμάτων είναι εκεί όπου τα APIs σιωπηλά πετυχαίνουν ή αποτυγχάνουν στον πραγματικό κόσμο: το happy path είναι εύκολο, αλλά οι καταναλωτές ξοδεύουν τον περισσότερο χρόνο debugging στη διαδρομή σφάλματος, και ένα ασυνεπές ή ασαφές συμβόλαιο σφάλματος κάνει την ενσωμάτωση βασανιστική. Οι συνεντευξιαστές το χρησιμοποιούν για να ελέγξουν δύο πράγματα. Πρώτον, **το status code μαζί με ένα δομημένο body να συνεργάζονται** — το status είναι το χονδρικό σήμα για τα εργαλεία και τα retries, το body μεταφέρει τη λεπτομέρεια πάνω στην οποία μπορείτε να ενεργήσετε — παρά το anti-pattern του `200 OK` με ένα σφάλμα μέσα. Δεύτερον, έναν **σταθερό, αναγνώσιμο από μηχανή κωδικό σφάλματος** (μέσω του `type` του RFC 7807 ή ενός πεδίου `code`) ώστε οι clients να κάνουν branch στο `"insufficient_funds"` αντί να κάνουν string-matching ένα αγγλικό μήνυμα που μπορεί να αναδιατυπωθεί ή να τοπικοποιηθεί. Η επιστροφή όλων των σφαλμάτων validation μαζί, και το να μη διαρρέετε ποτέ εσωτερικές λεπτομέρειες όπως stack traces, ολοκληρώνει μια απάντηση που δείχνει ότι έχετε χτίσει APIs που άλλες ομάδες έπρεπε πραγματικά να καταναλώσουν.

Χρησιμοποιήστε ένα τυπικό φορμά σφάλματος: RFC 7807 (problem+json)

Σφάλματα validation: αναφέρετέ τα όλα μαζί

Αρχές

Γιατί έχει σημασία

Σχετικές ερωτήσεις