treecode

REST API로 간단한 프로젝트를 만들어보고 있었는데 뭔가 만든다고는 하는데 막상 REST API가 뭔지 설명은 못하다가 좋은 영상을 보게 되었다.

REST API란 REST 아키텍쳐 스타일을 따르는 API로 REST는 서버와 클라이언트의 독립적인 진화를 위해 나오게 되었는데 REST를 구성하는 스타일은 다음과 같다.

1. client-server 구조

2. 무상태성(stateless)

3. cache

4. uniform interface

5. layered system

7. code-on-demand (Optional) - 서버에서 코드를 클라이언트로 보내서 실행할 수 있어야 한다. (Js)

대부분은 HTTP 특징을 잘 따르면 만족을 하는데 Uniform Interface는 처음 들어보는 용어인데 대부분 지키기가 어렵다고 한다.

Uniform Interface

1. identification of resources

2. manipulation of resources through representations

3. self-descriptive messages

4. hypermedia as ther engine of application state (HATEOAS)

1. identification of resources

리소스를 uri로 식별한다는 것으로 처음 Rest API를 공부할 때도 이 부분만 지키려고 했었다. (행위는 HTTP 메소드로 표현)

2. manipulation of resources through representations

representation이 조금 이해가 안 되어서 더 찾아보다가 좋은 글을 발견했다. (글을 쓰다 알았는데 위 영상에 나오시는 분이 이 글을 쓰신 분이였다..)

먼저 HTTP GET 메서드의 정의를 보면 Get 메서드가 타겟 리소스를 위해 현재 선택된 representation을 전송한다고 나와있다. 

The GET method requests transfer of a current selected representation
for the target resource.

이는 리소스를 표현하는 representation이 있고, replresentation이 하나 이상일 수 있으며 그 중 하나를 선택한다고 이해할 수 있다.

리소스는 HTTP 요청의 대상인데 회원에 대한 리소스를 요청을 했으면 아이디, 이름 등은 현재 회원이라는 리소스를 표현하는 데이터가 된다.

representation은 어떤 리소스의 특정 시점의 상태를 반영하고 있는 정보로 아이디가 바뀐다면 해당 리소스의 representation이 바뀌는 것이다.

김영한님 HTTP 강의에서 HTTP 표준 RFC7230 부분에도 나와있는데 Representation(표현)은 표현 메타데이터(헤더)와 표현 데이터(메시지 바디)로 구성이 되는데 표현 메타데이터는 표현 데이터를 해석할 수 있는 정보를 제공한다고 보면 된다. (Content-Type, Content_Lenght 등)

리소스에 대한 표현은 여러개가 될 수 있고 그 중 요청에 적합한 'a current selected representation' 을 선택해서 반환하는 것이다.

여기서 말하는 선택은 Request 요청 시 Accept 정보에 따라 서버에서 적절한 representation을 선택하는 것을 말하고 이를 협상(컨텐츠 네고시에이션)이라고 한다. (Accept-Language: ko 헤더를 추가하여 한국어 representation으로 응답을 받거나 Accept: text/html; charset=UTF-8을 추가하여 html로 응답을 받는 등 요청에 따라 응답이 달라진다.)

HTTP에서의 representation 개념은 REST에서 온 것인데 REST(Representational State Transfer)에서 State는 웹 애플리케이션의 상태를, Transfer은 상태의 전송을 의미한다.

브라우저가 보여주는 페이지가 바뀌는 것을 웹 애플리케이션의 상태가 변경되었다고 말하는데 표현(representation)을 통해 웹 애플리케이션의 상태(State)가 변경(Transfer)되는 것이다.  

이제 메시지 바디에 Representation을 담아서 리소스를 조작(생성, 변경, 삭제 등)한다는 것이 조금 이해가 되었다.

3. self-descriptive messages

self-descriptive message는 메세지가 스스로 설명 가능해야 한다는 것인데 json으로 응답을 하는 경우 Content-Type을 명시해주고 해당 json 값이 무엇을 의미하는지 json patch 명세를 확인해서 정의하는 등의 정보들을 제공해야한다.

4. hypermedia as ther engine of application state (HATEOAS)

HATEOAS는 애플리케이션의 상태가 하이퍼링크를 통해 전이가 되어야 한다는 것으로 HTML의 경우 단순하게 <a href=> 태그를 통해 그 다음 상태로 이동할 수 있고 json은 링크라는 것을 추가해서 다음 상태로 전이되도록 할 수 있다.

REST API는 대부분 Json으로 응답을 하기 때문에 HTML과 비교하면 self-descriptive, HATEOAS를 지키기가 어려운데 영상에 해결책이 나와있지만 확실히 HTML에 비해 까다로운 것 같다. 그래도 REST API가 무엇인지 이런 부분들을 좀 공부하니 내가 뭘 만드는지 조금 정리가 됐다.

간단하게 프로젝트에 스프링 HATEOAS를 추가해서 링크를 바디에 추가했는데 링크를 추가할 객체를 EntityModel.of()에 넣어주는데 new 생성자는 더 이상 사용 안하기 때문에 of()를 사용한다.

그리고 링크 빌더를 통해 readMemberList() 메서드의 url을 생성해주고 EntityModel에 담아서 보내면 되는데 사용자 리스트를 보여주는 메소드 링크를 연결하였다.