Apa itu HATEOAS dan Richardson Maturity Model?

Question

IT Interview Practice · Accepted Answer

**Richardson Maturity Model (RMM)** menilai seberapa "RESTful" sebuah API di sepanjang empat level, dan **HATEOAS** adalah level teratas — constraint yang paling banyak dilewati orang.

## Empat level

```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.
```

Sebagian besar API "REST" produksi berada di **Level 2** — resource, method, dan status code yang benar. Itu biasanya sudah cukup baik, dan itu adalah target yang sepenuhnya masuk akal.

## HATEOAS (Level 3)

**HATEOAS** = *Hypermedia As The Engine Of Application State*. Idenya: sebuah response menyertakan **link** yang memberitahu client aksi apa yang tersedia berikutnya, sehingga client menavigasi API dengan mengikuti link alih-alih menghardcode URL — seperti manusia yang mengikuti link di sebuah halaman web alih-alih 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" }
  }
}
```

Karena order-nya `pending`, server menawarkan link `pay` dan `cancel`. Setelah dibayar, link-link itu menghilang dan sebuah link `refund` mungkin muncul — **server yang mendorong transisi state**, dan client cukup mengikuti link apa pun yang diberikan kepadanya.

## Mengapa ia langka

Janjinya adalah decoupling: client tidak menghardcode URL, sehingga server bisa merestrukturisasinya dengan bebas. Dalam praktik sebagian besar client menghardcode juga, HATEOAS menambah kompleksitas nyata, dan formatnya tidak pernah sepenuhnya distandarkan (HAL, JSON:API, Siren semuanya bersaing). Imbalannya jarang membenarkan biayanya.

## Mengapa ini penting

Ini adalah pertanyaan level senior klasik karena ia memisahkan orang yang **memahami REST sebagaimana awalnya didefinisikan** dari mereka yang memakai "REST" secara longgar untuk berarti "JSON di atas HTTP." Wawasan yang berharga bukanlah membacakan empat level — melainkan penilaian untuk berkata bahwa **Level 2 adalah titik manis pragmatis** sambil mengetahui bahwa REST sejati (definisi Fielding) *mensyaratkan* HATEOAS, dan bisa menjelaskan *mengapa industri sebagian besar mengabaikannya*: manfaat decoupling itu nyata tetapi jarang terwujud karena client menghardcode URL tetap saja, dan kompleksitas tambahan plus format hypermedia yang bersaing tidak sepadan untuk API tipikal. Menunjukkan bahwa Anda tahu apa itu HATEOAS, bisa menampilkan contoh link-berbasis-state yang konkret, dan bisa berargumen jujur tentang biaya/manfaat — alih-alih secara dogmatis memaksa setiap API harus Level 3 — adalah persis penilaian yang seimbang dan berbasis pengalaman yang sedang diselidiki pewawancara.

Empat level

HATEOAS (Level 3)

Mengapa ia langka

Mengapa ini penting

Pertanyaan terkait