[개념쌓기] HATEOAS?

  HATEOAS란?

: Hypermedia As The Engine Of Application State

 서버가 클라이언트에 하이퍼 미디어를 통해 정보를 동적으로 제공하는 것

 

일반적으로 REST API를 사용하는 클라이언트가 전적으로 서버와 동적인 상호작용이 가능하도록 하는 것을 의미한다.

클라이언트가 서버로부터 어떠한 요청을 할 때, 요청에 필요한 URI를 응답에 포함시켜 반환하는 것으로 가능하게 한다

 

해당 리소스의 상태에 따라 링크 정보가 바뀌며 동적으로 리소스를 구성한다.

(이 말이 URI를 통해 무엇을 포함하는 지를 알려준다는 의미이다.)

예로 헤더에 Content Type을 application/hal + json으로 전달하면 클라이언트에서는 _links 필드에 링크 정보가 있다고 예상할 수 있다. 

---

Hateoas는 REST API를 잘 설계하기 위해 나온 개념이라고 했다.

알잘딱깔센 REST API를 쪼매 정리해봄.

 

🔔 REST API는 Representational State Transfer API의 약자로, 웹 애플리케이션이 제공하는 각각의 데이터를 리소스, 자원으로 간주하고 각각의 자원에 고유 URI를 할당해서 이를 표현하는 API를 정의하기 위한 소프트웨어 아키텍처 스타일이다.

 

위는 사전적 정의이고, 정보를 주고받는데 개발자들끼리 많이 쓰는 방식이라고 알면 된다.

 

 

출처 : https://images.app.goo.gl/tp6yVbK2Lrs16dcB8

 

출처 : https://grapeup.com/blog/how-to-build-hypermedia-api-with-spring-hateoas/

그럼 이제 REST API의 등급들에 대해 알아보며 Spring에서 어떻게 쓰는지에 대해 알아보자.

REST API를 구현함에도 여러 단계가 존재하는데 이것의 최상위 단계가 HATEOAS인 것이다.

일반적으로 REST API를 구현하는 단계는 Lvl 2라고 보면 된다. 

Lvl 2에서는 Resource와 HTTP 메소드를 사용하는 반면,

Lvl 3에서는 Lvl 2에 추가적으로 api를 탐색하는 링크들을 가지고 있다.

요청 예시를 보면 Lvl 2와 다를 것이 없어보이지만, Response를 보면 JSON + HAL이라는 것을 알 수 있다.

 

  HAL(Hardware Abstraction Layer,하드웨어 추상화 계층) 

: 하드웨어 추상화 계층은 컴퓨터 본체와 같은 물리적인 하드웨어와 OS 같은 컴퓨터에서 실행되는 소프트웨어 사이의 추상화 계층

 

일반적으로는 다음과 같이 정보가 제공된다.

{
	"User_id" : willeee_j,
	"Charge"  : "20000"
}

그러나 HATEOAS를 사용하면 추가 API들이 LINKS라는 이름으로 추가적으로 제공된다.

{
	"user_id" : willeee_j,
	"charge"  : "20000",
	"links" : [
    	{ 
        	"rel" : "self",
            "href" : "http://localhost:8080/user_id/12345"
        },{
        	"rel" : "withdraw",
            "href" : "http://localhost:8080/user_id/12345/withdraw"
        },{
        	"rel" : "transfer",
            "href" : "http://localhost:8080/user_id/12345/transfer"
        }
	]
}

위의 코드와 같이 HATEOAS를 사용하면 정보가 추가로 나온다.

Hypermedia As The Engine Of Application State - HATEOAS

Hypermedia : Data + Links 

즉, Lvl 2+ links라고 쓰여진 것처럼 연관된 링크도 응답(Response)로서 함께 담아서 보내주는 개념이라고 보면 된다.

이는 다른 것보다 추가적인 Action이 링크로 제공되어, 어떤 서비스를 해주는지 한눈에 볼 수 있다는 것이 장점이다.

 

💡그래서 왜 쓰냐고? WHY 목적 무엇

높은 수준에서 Client와 Server를 분리시키는 것, 의존성을 줄여 Client와 Server 각각 독립적으로 개발하기 위해서다

 

Client입장에서는 Server에서 url을 바꿔도 이름을 통해 접근을 하기에 영향이 없다. 

즉, Client, Sever가 각각 개발 진행이 가능하다.

 

 

Hypermedia를 표현하는 방식 : HAL(Hypertext Application Language) Model

resource의 JSON properties와 Links(rel/href)로 구성되고 ,embedded resources 내에서 다시 HAL로 표현된다.

HAL Model

---

 

😊HATEOAS의 장점

- 서버에서 URL을 변경해도 client에 영향이 없다

- api 제공 시 user에게 documentation(기록)을 자동으로 제공

- Front의 link유무에 따라, 다양한 UI 사용이 가능하다(ex- link가 없으면 버튼을 비활성화한다)

- Resource가 포함된 URI를 보여주기에 Resource에 대한 신뢰를 얻을 수 있다.

- URI 정보를 통해 요청을 예측할 수 있다.

- 동적으로 생성된 URI를 사용함으로써, 클라이언트가 URI 수정에 따라 코드를 변경하지 않아도 되는 편의성을 제공

- API의 변화에 모두 대응하지 않아도 되는 편리함을 제공

 

😂HATEOAS의 단점

- 전달하는 data크기가 커져서 네트워크 오버헤드가 생긴다

- 링크가 많아 복잡해진다

 

 

 

참고 자료 :

https://joomn11.tistory.com/26 

https://brunch.co.kr/@purpledev/29 

https://zeroco.tistory.com/103

https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html

https://kchanguk.tistory.com/117