Si funksionojnë rate limiting dhe HTTP caching në një REST API?

Question

IT Interview Practice · Accepted Answer

Rate limiting e mbron server-in nga tepër shumë request-e; HTTP caching shmang përsëritjen e punës për request-e që tashmë i ka përgjigjur. Të dyja janë të standardizuara në HTTP dhe të dyja janë thelbësore për një API production në shkallë të gjerë.

## Rate limiting

Serveri kufizon sa request-e mund të bëjë një client për çdo dritare kohore dhe kthen **`429 Too Many Requests`** kur tejkalohet. Ai i shpall limitet përmes headers që një client i sjellshëm të mund të vetë-frenohet:

```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-i `Retry-After` i thotë client-it saktësisht sa kohë të presë. Algoritmet e zakonshme: **token bucket** (lejon shpërthime (bursts) deri në madhësinë e bucket-it, mbushet sërish në mënyrë të qëndrueshme — zgjedhja e zakonshme), **sliding window**, dhe **fixed window** (më i thjeshti por me shpërthime në skajet e dritares). Çelësat janë zakonisht për çdo API key, user, ose IP, me counters në Redis për një flotë të shpërndarë.

## HTTP caching

Dy mekanizma plotësues:

**1. Skadimi (`Cache-Control`)** — serveri thotë sa kohë një response mbetet i freskët, kështu që client-i/CDN-ja e ripërdor pa **asnjë request fare**:
```http
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
```

**2. Validimi (`ETag` / conditional requests)** — kur freskia është e pasigurt, client-i rivalidon lirë. Serveri e etiketon një response me një **`ETag`** (një gjurmë gishti versioni); client-i e dërgon mbrapsht në `If-None-Match`, dhe nëse s'ka ndryshuar serveri kthen **`304 Not Modified`** **pa 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 gjithashtu fuqizojnë **optimistic concurrency**: dërgo `If-Match: "a1b2c3"` në një `PUT`, dhe serveri kthen `412 Precondition Failed` nëse dikush tjetër e ndryshoi resource-in i pari — duke parandaluar lost updates.

## Pse ka rëndësi

Bashkë këto janë mënyra si një REST API mbijeton shkallën, prandaj intervistuesit senior i përdorin për të kontrolluar pjekurinë operacionale. Për rate limiting, sinjali është që ti e trajton si një **kontratë bashkëpunuese** — duke ekspozuar headers `RateLimit-*` dhe `Retry-After` që client-ët të tërhiqen me hijeshi sesa të godasin murin — dhe që mund të emërtosh një algoritëm dhe ku ndodhet counter-i (Redis, për çdo çelës) në një shpërndarje të shpërndarë. Për caching, njohuria kryesore është **modeli dy-nivelësh**: skadimi (`max-age`) e eliminon request-in tërësisht, ndërsa validimi (`ETag`/`304`) i bën të lira request-et e pashmangshme duke kapërcyer body-n. Të përmendësh se ETags kryejnë detyrë të dyfishtë për **optimistic concurrency** (`If-Match` → `412`) tregon zotërim më të thellë të semantikave të HTTP-së. Kandidatët që i kuptojnë këto mekanizma janë ata që mund të ndërtojnë API që mbeten të shpejta dhe të qëndrueshme nën trafik real, që është pikërisht ajo çka po teston pyetja.

Rate limiting

HTTP caching

Pse ka rëndësi

Pyetje të ngjashme