Conas a oibríonn rate limiting agus HTTP caching in API REST?

Question

IT Interview Practice · Accepted Answer

Cosnaíonn rate limiting an server ó an iomarca iarratas; seachnaíonn HTTP caching obair a athdhéanamh d'iarratais a d'fhreagair sé cheana. Tá an dá cheann caighdeánaithe in HTTP agus tá an dá cheann riachtanach do API táirgthe ar scála.

## Rate limiting

Cuireann an server uasteorainn le cé mhéad iarratas is féidir le cliant a dhéanamh in aghaidh na fuinneoige agus filleann sé **`429 Too Many Requests`** nuair a sháraítear é. Fógraíonn sé teorainneacha trí headers ionas gur féidir le cliant dea-iompraithe é féin a scóig:

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

Insíonn an header `Retry-After` don chliant go beacht cé chomh fada le fanacht. Algartaim choitianta: **token bucket** (ceadaíonn sé bursts suas go méid an bucket, athlíonann sé go seasta — an gnáthrogha), **sliding window**, agus **fixed window** (is simplí ach burstach ag imill na fuinneoige). Bíonn eochracha in aghaidh gach API key, úsáideoir, nó IP de ghnáth, le cuntair in Redis do fhlít dháilte.

## HTTP caching

Dhá mheicníocht chomhlántacha:

**1. Éag (`Cache-Control`)** — deir an server cé chomh fada a fhanann freagra úr, mar sin athúsáideann an cliant/CDN é gan **aon iarratas ar chor ar bith**:
```http
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
```

**2. Bailíochtú (`ETag` / iarratais choinníollacha)** — nuair atá an úire éiginnte, athbhailíochtaíonn an cliant go saor. Clibeálann an server freagra le **`ETag`** (méarlorg leagain); seolann an cliant ar ais é in `If-None-Match`, agus mura n-athraíonn sé filleann an server **`304 Not Modified`** gan **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
```

Cumhachtaíonn ETaganna **optimistic concurrency** freisin: seol `If-Match: "a1b2c3"` ar `PUT`, agus filleann an server `412 Precondition Failed` má d'athraigh duine eile an acmhainn ar dtús — ag cosc nuashonruithe caillte.

## Cén fáth a bhfuil sé tábhachtach

Le chéile is mar seo a mhaireann API REST scála, mar sin úsáideann agallóirí sinsearacha iad chun aibíocht oibríochtúil a sheiceáil. Maidir le rate limiting, is é an comhartha go gcaitheann tú leis mar **chonradh comhoibríoch** — ag nochtadh headers `RateLimit-*` agus `Retry-After` ionas go gcúlaíonn cliaint go grástúil seachas bualadh isteach i mballa — agus gur féidir leat algartam a ainmniú agus an áit a gcónaíonn an cuntar (Redis, in aghaidh gach eochair) i leisiúchán dháilte. Maidir le caching, is é an léargas lárnach an **tsamhail dhá shraith**: baineann éag (`max-age`) an t-iarratas amach go hiomlán, fad a fhágann bailíochtú (`ETag`/`304`) na hiarratais dhosheachanta saor trí an body a scipeáil. Léiríonn é a lua go ndéanann ETaganna dhá dhualgas do **optimistic concurrency** (`If-Match` → `412`) ceannas níos doimhne ar shéimeantaic HTTP. Is iad na hiarrthóirí a thuigeann na meicníochtaí seo na cinn is féidir leo APIanna a thógáil a fhanann tapa agus cobhsaí faoi fhíorthrácht, arb é sin go díreach an rud atá á thástáil ag an gceist.

Rate limiting

HTTP caching

Cén fáth a bhfuil sé tábhachtach

Ceisteanna gaolmhara