Kif jaħdmu r-rate limiting u l-HTTP caching f'REST API?

Question

IT Interview Practice · Accepted Answer

Ir-rate limiting jipproteġi lis-server minn wisq requests; l-HTTP caching jevita li jirrepeti xogħol għal requests li diġà wieġeb. It-tnejn huma standardizzati fl-HTTP u t-tnejn huma essenzjali għal API tal-produzzjoni fuq skala.

## Rate limiting

Is-server jillimita kemm requests jista' jagħmel client għal kull tieqa u jirritorna **`429 Too Many Requests`** meta jinqabeż. Jirreklama l-limiti permezz ta' headers biex client li jġib ruħu sew ikun jista' jrażżan lilu nnifsu:

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

L-header `Retry-After` jgħid lill-client eżatt kemm għandu jistenna. Algoritmi komuni: **token bucket** (jippermetti bursts sad-daqs tal-bucket, jerġa' jimla b'mod kostanti — l-għażla tas-soltu), **sliding window**, u **fixed window** (l-aktar sempliċi imma bursty fit-truf tat-tieqa). Il-keys ġeneralment huma għal kull API key, user, jew IP, b'counters f'Redis għal flotta distribwita.

## HTTP caching

Żewġ mekkaniżmi komplementari:

**1. Skadenza (`Cache-Control`)** — is-server jgħid għal kemm żmien response jibqa' frisk, biex il-client/CDN jerġa' jużah **mingħajr ebda request**:
```http
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
```

**2. Validazzjoni (`ETag` / conditional requests)** — meta l-freskezza mhix ċerta, il-client jerġa' jivvalida bl-irħis. Is-server jimmarka response b'**`ETag`** (marka tas-swaba' tal-verżjoni); il-client jibagħtha lura f'`If-None-Match`, u jekk ma nbidlitx is-server jirritorna **`304 Not Modified`** b'**ebda 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
```

L-ETags jagħtu s-saħħa wkoll lill-**optimistic concurrency**: ibgħat `If-Match: "a1b2c3"` fuq `PUT`, u s-server jirritorna `412 Precondition Failed` jekk xi ħadd ieħor biddel ir-resource l-ewwel — u jipprevjeni lost updates.

## Għaliex huwa importanti

Flimkien dawn huma kif REST API tibqa' ħajja fuq skala, u għalhekk l-intervistaturi senior jużawhom biex jiċċekkjaw il-maturità operazzjonali. Għar-rate limiting, is-sinjal huwa li tittrattah bħala **kuntratt kooperattiv** — tesponi headers `RateLimit-*` u `Retry-After` biex il-clients jieqfu b'mod grazzjuż aktar milli jsawtu ġo ħajt — u li tista' ssemmi algoritmu u fejn jgħix il-counter (Redis, għal kull key) f'deployment distribwit. Għall-caching, l-għarfien ewlieni huwa l-**mudell b'żewġ saffi**: l-iskadenza (`max-age`) telimina r-request kompletament, filwaqt li l-validazzjoni (`ETag`/`304`) tagħmel ir-requests inevitabbli rħas billi taqbeż il-body. Li ssemmi li l-ETags jagħmlu doppju xogħol għall-**optimistic concurrency** (`If-Match` → `412`) juri kmand aktar profond tas-semantika tal-HTTP. Il-kandidati li jifhmu dawn il-mekkaniżmi huma dawk li jistgħu jibnu APIs li jibqgħu mgħaġġla u stabbli taħt traffic reali, li huwa eżatt dak li l-mistoqsija qed tittestja.

Rate limiting

HTTP caching

Għaliex huwa importanti

Mistoqsijiet relatati