ما هو HATEOAS ونموذج Richardson Maturity Model؟

Question

IT Interview Practice · Accepted Answer

يقيّم **Richardson Maturity Model (RMM)** مدى "RESTful"-ية الـ API عبر أربعة مستويات، والـ **HATEOAS** هو المستوى الأعلى — القيد الذي يتخطّاه معظم الناس.

## المستويات الأربعة

```text
Level 0 — "The Swamp of POX": one URI, one method (RPC over HTTP).
          POST /api  { "action": "getUser", "id": 42 }
Level 1 — Resources: many URIs, but still one verb.
          POST /users/42  ,  POST /users/42/delete
Level 2 — HTTP Verbs: proper methods + status codes (where most "REST" APIs live).
          GET /users/42 → 200 ,  DELETE /users/42 → 204
Level 3 — Hypermedia Controls (HATEOAS): responses link to what you can do next.
```

معظم واجهات "REST" في الإنتاج عند **المستوى 2** — موارد وmethods وstatus codes صحيحة. وهذا عادةً جيّد بما يكفي، وهو هدف معقول تمامًا.

## HATEOAS (المستوى 3)

الـ **HATEOAS** = *Hypermedia As The Engine Of Application State*. الفكرة: تتضمّن الاستجابة **روابط (links)** تخبر العميل بالأفعال المتاحة تاليًا، فيتنقّل العميل في الـ API باتّباع الروابط بدل ترميز عناوين URL بشكل صلب — كإنسان يتّبع روابط على صفحة ويب بدل حفظ كل URL.

```http
GET /orders/1001 HTTP/1.1
```
```http
HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 1001,
  "status": "pending",
  "total": 250,
  "_links": {
    "self":   { "href": "/orders/1001" },
    "pay":    { "href": "/orders/1001/payment", "method": "POST" },
    "cancel": { "href": "/orders/1001/cancel",  "method": "POST" }
  }
}
```

لأن الطلب `pending`، يقدّم الخادم رابطَي `pay` و`cancel`. وبمجرّد الدفع، تختفي تلك الروابط وقد يظهر رابط `refund` — **الخادم يقود انتقالات الحالة**، والعميل يتّبع الروابط المعطاة له فحسب.

## لماذا هو نادر

الوعد هو فكّ الاقتران (decoupling): لا يرمّز العملاء عناوين URL بشكل صلب، فيستطيع الخادم إعادة هيكلتها بحرية. عمليًّا، معظم العملاء يرمّزونها بشكل صلب رغم ذلك، وHATEOAS يضيف تعقيدًا حقيقيًّا، والصيغ لم تُقنَّن بالكامل قطّ (HAL، JSON:API، Siren تتنافس جميعها). نادرًا ما يبرّر العائد الكلفة.

## لماذا يهم

هذا سؤال senior كلاسيكي لأنه يفصل من **يفهمون REST كما عُرِّف أصلًا** عمن يستخدمون "REST" بتساهل ليعني "JSON فوق HTTP". البصيرة القيّمة ليست سرد المستويات الأربعة — بل الحُكم بأن **المستوى 2 هو النقطة الحلوة العملية** مع العلم بأن REST الحقيقي (تعريف Fielding) *يتطلّب* HATEOAS، والقدرة على تفسير *لماذا تتجاهله الصناعة في الغالب*: فائدة فكّ الاقتران حقيقية لكن نادرًا ما تتحقّق لأن العملاء يرمّزون عناوين URL بشكل صلب على أي حال، والتعقيد المضاف إضافةً إلى صيغ الـ hypermedia المتنافسة لا يجدي للواجهات النمطية. إظهار أنك تعرف ما *هو* HATEOAS، وتقدر على عرض مثال ملموس لروابط مقودة بالحالة، وتقدر على الجدل بصدق حول الكلفة/الفائدة — بدل الإصرار العقائدي على أن كل API يجب أن يكون بالمستوى 3 — هو بالضبط الحُكم المتوازن القائم على الخبرة الذي يسبره المُقابِلون.

المستويات الأربعة

HATEOAS (المستوى 3)

لماذا هو نادر

لماذا يهم

أسئلة ذات صلة