스프링 HATEOAS는 HATEOAS 원칙을 준수하는 API를 생성하는 작은 프로젝트이다.
이 원칙에 따르면 API는 각 서비스 응답과 함께 가능한 다음 단계 정보도 제공하며, 클라이언트를 다음 단계로 가이드할 수 있어야 한다.
Why?
1. REST API를 구현하다 보면 흔히 무엇을 놓칠까?
우리는 웹 개발을 하다 보면 많은 경우 REST API를 이용한다.
REST API란 인터넷 상의 시스템 간 상호 운용성을 제공하는 방법 중 하나이다.
이 때 REST API에는 필수 제약 조건들이 있는데 그 중 하나라도 지켜지지 않는다면 REST API라고 할 수 없다. (자세한 제약 조건은 참고 링크 확인)
제약 조건들 중 Uniform Interface가 있는데 대부분의 REST API라는 것들에서 Uniform Interface가 지켜지지 않는다.
이는 URL로 지정된 리소스에 대한 조작을 통일하고 한정된 인터페이스로 수행하는 아키텍처 스타일이다.
아래는 Uniform Interface의 4가지 제약 조건이다.
- Resource-Based
- Manipluation Of Resources Through Representations
- Self-Descriptive Message
- Hypermedia As The Engine of Application State
1, 2번은 "URI로 지정한 리소스를 Http Method를 통해서 표현하고 구분한다"로 해석 가능하다.
1, 2번은 우리가 흔히 잘 지키고 있는 반면 3, 4번은 많이 놓치고 있다.
2. HATEOS는 무엇을 해결해줄 수 있을까?
Uniform Interface의 3번, Self-Descriptive Message는 메시지 스스로가 자신에 대해 설명할 수 있어야 한다는 의미이다.
즉, API 문서가 REST API 응답 본문에 존재해야 한다는 것이다.
물론 API 문서 전체를 응답에 넣는 것은 불가능하니 적어도 API의 문서 위치정도는 알려줘야 한다는 것이다.
이렇게 하면 우리는 서버가 변해서 Response Data가 변경되었다고 가정했을 때, 클라이언트에서는 해당 API 문서를 통해 어떤 데이터가 바뀌었는지 알 수 있게 된다.
그리고 4번, HATEOS(Hypermedia As The Engine of Application State)는 링크를 통해 우리는 정보를 제공받아야 한다는 의미이다.
바로 아래와 같이 말이다.
위 사진은 아래 마이크로서비스 구축 과정 프로젝트에서 응답 받은 결과이다.
이제 스프링을 통해 우리가 제공하는 서비스에 HATEOAS를 구현해보자.
-
기존 License 클래스를 통해 RepresentationModel<> 상속 받기
-
LicenseController에 링크 추가하기
위와 같은 코드를 통해 우리는 온전한 REST API를 구현할 수 있다.
