HATEOAS 간단 소개, 과연 이게 정답인가?

외부 칼럼들을 읽다가 HATEOAS라는 것을 알게 되었다.

안그래도 회사에서 신규 프로젝트를 진행하게 되었는데, endpoint를 명확하게 정하지 못해 FrontEnd개발자분께 해당 내용을 전달드리지 못하고 있었다.
이유는 Restful하게 API를 구성하고 싶었고, 초기에 어느정도 Fix된 상태로 줘야 FrontEnd개발자분들이 편하게 작업이 가능하다고 말씀하셔서 정의에 대해 계속 생각하다보니 미뤄지고 그랬다.

그러던 와중 HATEOAS를 적용하면 이러한 문제를 해결할 수도 있다고 생각했다.

HATEOAS?

이부분은 그냥 밑의 구조를 보면 이해하기 편하다

{
  "data": { 
    "id": 1000,
    "name": "게시글 1",
    "content": "내용 1"
  },
  "_links": { 
    "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 주소
    }
  }
}

일반적인 API 구조에 _links라는 것을 달아서 다음 API는 뭘 호출해야할지, 상세한 API는 무엇인지 등에 대한 경로를 적어놓는거라 보면된다.

이 부분으로 인해서 _links에 적힌값의 키를 통하여 Frontend개발자가 이를 호출하여 기능을 수행하는 방법이다.
key 값으로 조회하고 value에 있는 API 정보로 호출하다보니 FronetEnd입장에서는 endpoint가 변경되어도 상관없다는 장점이 있으나..

단점

결국 API를 호출하기 위해서는 최소 2번의 호출이 있어야한다. 첫 번째는 실제 사용할 API에대한 정보를 담은 API를 호출하고 두 번째 API는 실제 호출되는 API이다. 네트워크 부담이 존재한다.

프론트 엔드 개발자 입장에서도 상태관리를 추가해줘야되고, 백엔드 개발자 입장에서도 로그도 따로 관리해야할 것이다. 그리고 초기 endpoint 설계에서는 도움이 될 수 있지만 어느정도 fix된 형태로 나가는 운영환경에서는 쓰일 일이 없을거라 생각했다.

그리고 구현코드를 보면 설정도 복잡한 편이다. 따로 link들을 property에 담아주는 작업을 해야하는데, 코드가 장황해지고 지저분해질 가능성이 커보였다.

또한 요구사항이 변경되면 저 링크들도 바꿔줘야하는데 이 기준도 모호하다고 생각했다. API하나를 Restful하게 짜기위해서는 인생은 너무 짧다.

결론

분명 HATEOAS의 방향 자체는 Restful API에 다가가기 위함은 알겠다.
초기 API 설계에서 유용할 수는 있지만, 운영 단계에서는 정적인 엔드포인트가 더 유리하다. API 유지보수 측면에서도 과연 이 방식이 장점이 될지는 고민해볼 필요가 있다.