كيف يعمل الـ rate limiting والـ HTTP caching في REST API؟

Question

IT Interview Practice · Accepted Answer

يحمي الـ rate limiting الخادم من كثرة الطلبات؛ ويتفادى الـ HTTP caching تكرار العمل لطلبات أجاب عنها بالفعل. كلاهما مُقنَّن في HTTP وكلاهما جوهري لـ API إنتاجيّ عند الحجم الكبير.

## Rate limiting

يحدّ الخادم عدد الطلبات المسموح للعميل بها في كل نافذة، ويُرجع **`429 Too Many Requests`** عند التجاوز. ويعلن الحدود عبر headers ليتمكّن عميل حسن السلوك من تنظيم نفسه:

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

يخبر رأس `Retry-After` العميل بالمدة التي يجب أن ينتظرها بالضبط. الخوارزميات الشائعة: **token bucket** (يسمح بدفقات (bursts) حتى حجم الدلو، ويُعاد ملؤه بثبات — الخيار المعتاد)، و**sliding window**، و**fixed window** (الأبسط لكنه دَفَقيّ عند حواف النافذة). المفاتيح عادةً لكل API key، أو مستخدم، أو IP، مع عدّادات في Redis لأسطول موزّع.

## HTTP caching

آليتان متكاملتان:

**1. الانتهاء (`Cache-Control`)** — يقول الخادم كم تبقى الاستجابة طازجة، فيعيد العميل/الـ CDN استخدامها بـ **دون أي طلب على الإطلاق**:
```http
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
```

**2. التحقّق (`ETag` / الطلبات الشرطية)** — حين تكون الطزاجة غير مؤكّدة، يعيد العميل التحقّق برخص. يوسم الخادم الاستجابة بـ **`ETag`** (بصمة إصدار)؛ يعيدها العميل في `If-None-Match`، وإن لم تتغيّر يُرجع الخادم **`304 Not Modified`** بـ **دون جسم**:

```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`، فيُرجع الخادم `412 Precondition Failed` إن غيّر شخص آخر المورد أولًا — مانعًا التحديثات الضائعة (lost updates).

## لماذا يهم

معًا، هكذا ينجو REST API من الحجم الكبير، لذا يستخدمها المُقابِلون الـ senior للتحقق من النضج التشغيلي. بالنسبة للـ rate limiting، الإشارة أنك تعامله كـ **عقد تعاونيّ** — كاشفًا headers `RateLimit-*` و`Retry-After` ليتراجع العملاء بلطف بدل الاصطدام بجدار — وأنك تستطيع تسمية خوارزمية ومكان العدّاد (Redis، لكل مفتاح) في نشرٍ موزّع. بالنسبة للـ caching، البصيرة الأساسية هي **النموذج ذو الطبقتين**: الانتهاء (`max-age`) يُلغي الطلب كليًّا، بينما التحقّق (`ETag`/`304`) يجعل الطلبات التي لا مفرّ منها رخيصة بتخطّي الجسم. وذكر أن الـ ETags تؤدّي دورًا مزدوجًا للـ **optimistic concurrency** (`If-Match` → `412`) يُظهر تمكّنًا أعمق من دلالات HTTP. المرشّحون الذين يفهمون هذه الآليات هم من يستطيعون بناء واجهات تبقى سريعة ومستقرة تحت حركة مرور حقيقية، وهو بالضبط ما يختبره السؤال.

Rate limiting

HTTP caching

لماذا يهم

أسئلة ذات صلة