Πώς λειτουργούν το rate limiting και το HTTP caching σε ένα REST API;

Question

IT Interview Practice · Accepted Answer

Το rate limiting προστατεύει τον server από πάρα πολλά requests· το HTTP caching αποφεύγει την επανάληψη δουλειάς για requests που έχει ήδη απαντήσει. Και τα δύο είναι τυποποιημένα στο HTTP και τα δύο είναι απαραίτητα για ένα API παραγωγής σε κλίμακα.

## Rate limiting

Ο server περιορίζει πόσα requests μπορεί να κάνει ένας client ανά παράθυρο και επιστρέφει **`429 Too Many Requests`** όταν ξεπεραστεί. Διαφημίζει τα όρια μέσω headers ώστε ένας καλά συμπεριφερόμενος client να μπορεί να αυτο-ρυθμίζεται:

```http
HTTP/1.1 200 OK
RateLimit-Limit: 100
RateLimit-Remaining: 12
RateLimit-Reset: 30
```

```http
HTTP/1.1 429 Too Many Requests
Retry-After: 30

{ "error": "rate limit exceeded, retry in 30s" }
```

Το header `Retry-After` λέει στον client ακριβώς πόσο να περιμένει. Συνηθισμένοι αλγόριθμοι: **token bucket** (επιτρέπει bursts μέχρι το μέγεθος ενός bucket, ξαναγεμίζει σταθερά — η συνήθης επιλογή), **sliding window**, και **fixed window** (ο πιο απλός αλλά με bursts στα άκρα του παραθύρου). Τα κλειδιά είναι συνήθως ανά API key, user, ή IP, με counters στο Redis για έναν κατανεμημένο στόλο.

## HTTP caching

Δύο συμπληρωματικοί μηχανισμοί:

**1. Λήξη (`Cache-Control`)** — ο server λέει πόσο μια απόκριση παραμένει φρέσκια, ώστε ο client/CDN να την επαναχρησιμοποιήσει με **κανένα request καθόλου**:
```http
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
```

**2. Επικύρωση (`ETag` / conditional requests)** — όταν η φρεσκάδα είναι αβέβαιη, ο client επαναεπικυρώνει φθηνά. Ο server επισημαίνει μια απόκριση με ένα **`ETag`** (ένα αποτύπωμα έκδοσης)· ο client το στέλνει πίσω στο `If-None-Match`, και αν δεν έχει αλλάξει ο server επιστρέφει **`304 Not Modified`** με **κανένα body**:

```http
GET /users/42 HTTP/1.1
If-None-Match: "a1b2c3"
```
```http
HTTP/1.1 304 Not Modified      ← empty body, saves bandwidth
```

```text
Fresh (within max-age)   → served from cache, 0 requests
Stale but ETag matches   → 304, tiny response, no re-render
Stale and changed        → 200 with new body + new ETag
```

Τα ETags τροφοδοτούν επίσης το **optimistic concurrency**: στείλτε `If-Match: "a1b2c3"` σε ένα `PUT`, και ο server επιστρέφει `412 Precondition Failed` αν κάποιος άλλος άλλαξε τον πόρο πρώτος — αποτρέποντας χαμένες ενημερώσεις (lost updates).

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

Μαζί αυτά είναι ο τρόπος με τον οποίο ένα REST API επιβιώνει την κλίμακα, οπότε οι senior συνεντευξιαστές τα χρησιμοποιούν για να ελέγξουν τη λειτουργική ωριμότητα. Για το rate limiting, το σήμα είναι ότι το αντιμετωπίζετε ως ένα **συνεργατικό συμβόλαιο** — εκθέτοντας τα headers `RateLimit-*` και `Retry-After` ώστε οι clients να κάνουν back off με ευγένεια αντί να χτυπάνε σε έναν τοίχο — και ότι μπορείτε να ονομάσετε έναν αλγόριθμο και το πού ζει ο counter (Redis, ανά key) σε μια κατανεμημένη ανάπτυξη. Για το caching, η βασική διορατικότητα είναι το **μοντέλο δύο επιπέδων**: η λήξη (`max-age`) εξαλείφει εντελώς το request, ενώ η επικύρωση (`ETag`/`304`) κάνει τα αναπόφευκτα requests φθηνά παρακάμπτοντας το body. Η αναφορά ότι τα ETags κάνουν διπλή δουλειά για το **optimistic concurrency** (`If-Match` → `412`) δείχνει βαθύτερη γνώση της σημασιολογίας HTTP. Οι υποψήφιοι που κατανοούν αυτούς τους μηχανισμούς είναι εκείνοι που μπορούν να χτίσουν APIs που παραμένουν γρήγορα και σταθερά κάτω από πραγματική κίνηση, που είναι ακριβώς αυτό που ελέγχει η ερώτηση.

Rate limiting

HTTP caching

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

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