REST API와 HATEOAS에 대해

곧 큰 프로젝트에서 API 설계부터 들어가게 될텐데 

REST API 설계 규칙에 대해 정리하다 처음 접하는 개념이 있어 간단하게 정리해본다. 

 

REST API도 성숙도 모델에 따라 단계별로 나누게 되는데 

(사람마다 3단계라고 부르기도, 4단계라고 부르기도 하지만) 

이 HATEOAS를 적용했냐에 따라 마지막 단계의 모델인지 아닌지로 나뉘는듯 하다. 

 

HATEOAS의 뜻은 풀이하자면

Hypermedia As The Engine Of Application State 

즉, Hypermedia(링크)를 통해 애플리케이션의 상태 전이가 가능해야 하고, 

Hypermedia(링크)에 자기 자신의 정보가 담겨야 한다는 개념이다. 

 

아직도 이해하기 어렵다면 아래 예제를 보면 바로 이해될 것이다. 

 

보통 다뤄온 response 에 대한 JSON 값이 아래와 같았을 것이다. 

{
  "data": {
    "name": "seonghun"
  }
}

나조차도 이유도 모른채 습관적으로 데이터들을 data 라는 key 값에 담아 다뤄왔었는데

만약 HATEOAS를 적용한다면 아래와 같아진다. 

 

{
  "data": {
    "name": "seonghun"
  }, 
  "_link": {
    "self": {
      "href": "http://localhost:8080/api/article/1000" // 현재 api 주소
    },
    "profile": {
      "href": "http://localhost:8080/docs#query-article" // 해당 api의 문서
    },
    "next": {
      "href": "http://localhost:8080/api/article/1001" // article 의 다음 api 주소
    },
    "prev": {
      "href": "http://localhost:8080/api/article/999" // article의 이전 api 주소
    }
  }
}

이렇게 함으로서 링크에 대한 정보가 변경되어도 클라이언트에서 대응하지 않아도 되게 된다. 

 

* HATEOAS 대신 응답 헤더의 Content-Location 속성을 이용해도 된다는데 이 부분에 대해선 좀 더 확인해봐야겠다.

 

 

더 자세한 내용은 아래 참고

참고한 곳: https://wonit.tistory.com/454

HATEOAS를 모르면 당신이 알고 있는 REST API는 REST API가 아니라고 장담할게요.