HATEOAS와 Richardson Maturity Model이란 무엇인가?

Question

IT Interview Practice · Accepted Answer

**Richardson Maturity Model(RMM)**은 API가 얼마나 "RESTful"한지를 네 단계로 채점하며, **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.
```

production의 대부분 "REST" API는 **Level 2** — 올바른 리소스, method, status code — 다. 보통 그것으로 충분하며, 완벽하게 합리적인 목표다.

## HATEOAS (Level 3)

**HATEOAS** = *Hypermedia As The Engine Of Application State*. 아이디어: response가 다음에 어떤 동작이 가능한지 client에게 알려 주는 **링크**를 포함하므로, client는 URL을 하드코딩하는 대신 링크를 따라 API를 탐색한다 — 사람이 모든 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" }
  }
}
```

order가 `pending`이므로 server는 `pay`와 `cancel` 링크를 제공한다. 결제되면 그 링크들은 사라지고 `refund` 링크가 나타날 수 있다 — **server가 상태 전이를 이끌고**, client는 주어진 링크를 따르기만 한다.

## 왜 드문가

약속은 decoupling이다: client가 URL을 하드코딩하지 않으므로 server가 자유롭게 재구성할 수 있다. 실제로는 대부분의 client가 어차피 하드코딩하고, HATEOAS는 실질적 복잡성을 더하며, 형식은 결코 완전히 표준화되지 않았다(HAL, JSON:API, Siren이 모두 경쟁). 이득이 비용을 정당화하는 경우는 드물다.

## 왜 중요한가

이는 고전적인 senior 수준 질문인데, **REST를 원래 정의대로 이해하는** 사람과 "REST"를 "HTTP 위의 JSON"을 뜻하는 느슨한 말로 쓰는 사람을 가르기 때문이다. 가치 있는 통찰은 네 단계를 읊는 것이 아니라 — **Level 2가 실용적 스위트 스팟**이라고 말하는 판단력이다. 동시에 진짜 REST(Fielding의 정의)는 HATEOAS를 *요구*한다는 것을 알고, *왜 업계가 대체로 그것을 무시하는지*를 설명할 수 있어야 한다: decoupling 이득은 실재하지만 client가 어차피 URL을 하드코딩하기에 좀처럼 실현되지 않고, 더해지는 복잡성에 경쟁하는 hypermedia 형식까지 겹쳐 일반적인 API에는 수지가 맞지 않는다. HATEOAS가 *무엇인지* 알고, 구체적인 상태 기반 링크 예시를 보여 주며, 비용/이득을 정직하게 논할 수 있는 것 — 모든 API가 Level 3이어야 한다고 교조적으로 고집하는 대신 — 이 바로 면접관이 찾는, 경험에 근거한 균형 잡힌 판단력이다.

네 단계

HATEOAS (Level 3)

왜 드문가

왜 중요한가

관련 질문