Apakah itu HATEOAS dan Richardson Maturity Model?

Question

IT Interview Practice · Accepted Answer

**Richardson Maturity Model (RMM)** menggredkan betapa "RESTful" sesuatu API merentas empat tahap, dan **HATEOAS** ialah tahap tertinggi — kekangan yang kebanyakan orang langkau.

## Empat tahap

```text
Tahap 0 — "Paya POX": satu URI, satu method (RPC atas HTTP).
          POST /api  { "action": "getUser", "id": 42 }
Tahap 1 — Resources: banyak URI, tetapi masih satu kata kerja.
          POST /users/42  ,  POST /users/42/delete
Tahap 2 — HTTP Verbs: method + status code yang betul (tempat kebanyakan "REST" API berada).
          GET /users/42 → 200 ,  DELETE /users/42 → 204
Tahap 3 — Hypermedia Controls (HATEOAS): response memaut ke apa yang boleh anda lakukan seterusnya.
```

Kebanyakan "REST" API production berada di **Tahap 2** — resource, method, dan status code yang betul. Itu biasanya cukup baik, dan ia sasaran yang munasabah sepenuhnya.

## HATEOAS (Tahap 3)

**HATEOAS** = *Hypermedia As The Engine Of Application State*. Ideanya: response menyertakan **pautan** yang memberitahu client tindakan mana yang tersedia seterusnya, jadi client menavigasi API dengan mengikuti pautan dan bukannya meng-hardcode URL — seperti manusia mengikuti pautan pada laman web dan bukannya menghafal setiap 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" }
  }
}
```

Oleh sebab order itu `pending`, server menawarkan pautan `pay` dan `cancel`. Setelah dibayar, pautan itu hilang dan pautan `refund` mungkin muncul — **server memandu peralihan keadaan**, dan client hanya mengikuti apa jua pautan yang diberikan kepadanya.

## Mengapa ia jarang

Janjinya ialah penyahgandingan (decoupling): client tidak meng-hardcode URL, jadi server boleh menstruktur semula URL dengan bebas. Dalam praktik kebanyakan client tetap meng-hardcode, HATEOAS menambah kerumitan sebenar, dan format tidak pernah sepenuhnya dipiawaikan (HAL, JSON:API, Siren semuanya bersaing). Ganjaran jarang mewajarkan kos.

## Mengapa ia penting

Ini soalan peringkat senior klasik kerana ia memisahkan orang yang **memahami REST seperti ditakrifkan asalnya** daripada mereka yang menggunakan "REST" secara longgar bermaksud "JSON atas HTTP." Cerapan yang bernilai bukan melafazkan empat tahap — ia pertimbangan untuk menyatakan bahawa **Tahap 2 ialah titik manis pragmatik** sambil mengetahui bahawa REST sebenar (definisi Fielding) *memerlukan* HATEOAS, dan mampu menjelaskan *mengapa industri kebanyakannya mengabaikannya*: manfaat penyahgandingan adalah nyata tetapi jarang terealisasi kerana client tetap meng-hardcode URL, dan kerumitan tambahan serta format hypermedia yang bersaing tidak berbaloi untuk API biasa. Menunjukkan anda tahu HATEOAS *itu apa*, boleh menunjukkan contoh pautan-dipandu-keadaan yang konkrit, dan boleh berhujah dengan jujur tentang kos/manfaat — dan bukannya secara dogmatik mendesak setiap API mesti Tahap 3 — itulah tepatnya pertimbangan seimbang berasaskan pengalaman yang disiasat penemu duga.

Empat tahap

HATEOAS (Tahap 3)

Mengapa ia jarang

Mengapa ia penting

Soalan berkaitan