이놈의 REST API는 알면 알수록 끝이 없는 것 같습니다. REST API라는 것이 좋은 기술이고 설명도 왠만해서 간단하게 제공되고 있는 터라 어렵지 않게 생각하고 있었는데.. 알면 알수록 더욱 깊어지는 것은 다른 지식들과 별반 차이가 없더군요.
무튼 이번에 다룰 내용은 HATEOAS 입니다.
HATEOAS
= Hypermedia As The Engine Of Application State
제가 즐겨 보는 포프TV에서는 이것을 HATE한 OS(OS에 대한 의미가 명확하지 않았지만, HATE에 대한 언급은 명확하더군요)라고 표현하던데, 실제 OS와 관련된 내용은 아닙니다.
Martin Fowler라는 사람이 2010년 제안한 Richardson Maturity Model (Richardson 성숙도 모델) 에 의하면 총 4단계로 REST API의 요소를 구성하고 있습니다.
웹서비스들이 RESTful한 구현 결과를 향해 나아가는 ‘아주 멋진’ 그림이라고 생각합니다. 이처럼 RESTful API를 사용하는 클라이언트가 전적으로 서버와 동적인 상호작용이 가능하도록 하는 것을 HATEOAS라고 부릅니다.
이러한 방법은 클라이언트가 서버로부터 어떠한 요청을 할 때, 요청에 필요한(의존되는) URI를 응답에 포함시켜 반환 하는 것으로 가능하게 할 수 있습니다.
하지만 불과 몇년전만 하더라도 HATEOAS는 ‘희망적인 개념’일 뿐, 실제 사용되는 경우가 많이 없었습니다. 우선 이제까지 작성된 대부분의 요청문을 바꿔야 하는 번거로움도 있었지만, 더 중요한 것은 이 방식에 대한 장점이 명확하게 드러나지 못했던 부분도 있었기 때문이었죠.
예를 들어 사용자 정보를 생성(POST)하는 요청 이후, 이를 조회(GET), 수정(PUT), 삭제(DELETE)할 때, 이러한 모든 동작을 URI를 이용하여 동적으로 알려준다 는 의미입니다.
글만 봐서는 잘 이해가 가지 않을 수 있습니다. 코드를 살펴봅시다.
위 예제는 Spring에서 HATEOAS를 사용하는 경우를 보여줍니다. 각 기능마다 URI를 링크 시킴으로써, 동적인 API 제공이 가능하도록 합니다.
보시면 Alice라는 이름과 그 밑에 링크로 customer/1을 할당하는 것을 볼 수 있습니다. 이를 통해 URI에서 제공하는 메소드를 요청할 경우, 이를 동적으로 보여줄 수 있게 됩니다.
(추가적인 소스는 이곳을 통해 확인하실 수 있습니다)
이렇게 하면 다음과 같은 장점을 가질 수 있습니다.
- 요청 URI가 변경되더라도 클라이언트에서 동적으로 생성된 URI를 사용함으로써, 클라이언트가 URI 수정에 따른 코드를 변경하지 않아도 되는 편리함을 제공합니다.
- URI 정보를 통해 들어오는 요청을 예측할 수 있게 됩니다.
- Resource가 포함된 URI를 보여주기 때문에, Resource에 대한 확신을 얻을 수 있습니다.
조금 더 쉽게 표현하자면,
클라이언트를 개발하는 사람들이 특정 메소드로부터 올 수 있는 결과 동작에 대해 예측하는 것이 가능해지고, API가 변경되더라도 키가 바뀌지 않는 한 URI로 주어진 링크(link)만 유지하면 되므로 별도의 대응이 요구되지 않게 됩니다.
즉, 클라이언트가 제공되는 API의 변화에 일일이 대응하지 않아도 되는 엄청난 편리함을 제공받게 되는 것이죠.
포스팅 내용이 조금 길어졌네요.
위에서 언급한 Richardson Maturity Model은 다음 포스팅에서 언급해보도록 하겠습니다.
월리공방 
“REST API의 이상향, HATEOAS”의 1개의 생각