HATEOAS를 알아보다 알게 된 것들… (REST API, Charset, Link)

Explanation

오늘은 HATEOAS(Hypermedia As The Engine Of Application State)에 대해 알아보다가 알게된 그 밖의 것들에 대해 정리해 보려고 합니다.
HATEOAS로 시작했지만, 오늘의 포스팅은 HATEOAS에 대한 글은 아닐 거 같아요.
(사실 HATEOAS에 대해 글을 적을 만큼 아직 잘 알지 못해요..)
작성할 글의 키워드를 미리 요약하면 REST API, Charset 그리고 HTTP Header의 Link에 대해 이야기해보려 해요.

‘HATEOAS’는 어떻게 읽는 걸까요..? 헤이트이오아스..??

1. REST API

누군가 만약 저에게 API는 어떻게 만드냐고 물어봤다면, 아마도 전 RESTful 하게 만든다고 말 했을 거 같아요.
그동안 많은 API를 상의하며 만들고 사용 해왔고, API URI를 정할때도 꽤 오랜시간을 고민하며 만들었거든요.

그런데 HATEOAS를 알아보던 중 발견한 https://blog.npcode.com/(Yi EungJun님)의 글들을 읽어보며..
아… 내가 그동안 하던 방식이 REST API가 아니였구나…
(아주 REST에 대해 자세하고 친절하게 적어주셔서 한번 읽어보시면 정말 좋을 거 같아요.)

물론 엄격하게 REST API를 사용했다 할 순 없지만,
또 한편으로는 ‘REST API를 지향했다’ 정도로 의미를 갖을 수 있지 않을까.. 싶기도 하고 그러네요.
여하튼,

2. Charset

그리고 같은 https://blog.npcode.com/(Yi EungJun님)의 슬라이드를 보다가 갸우뚱한 부분이 있었어요.
슬라이드: https://slides.com/eungjun/rest#/47

두둥. charset이 케릭터 셋이 아니였단 말인가?!

그리고 슬라이드에 첨부된 참고 링크를 찾아가 보았답니다.
http://w3-org.9356.n7.nabble.com/How-to-pronounce-quot-charset-quot-td254585.html#message254629

그래서 믿을 만한 우리의 MDN 형님에게 가서 확인해 보았답니다.
https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/Accept-Charset

혼란스러웠지만, 혹시 하는 마음으로 언어를 영어로 변경하여 확인해 보았답니다.

짜잔!
아.. 그렇습니다. Charset은 ‘character set’의 약자로 만들어진건 맞는 거 같은데, 하지만 정확하게 여기서 Charset은 ‘character set’란 이름과 다르게 ‘character encodings’를 의미하고 있던 것입니다.

‘character set’과 ‘character encodings’의 차이는 아래의 블로그 글을 보시면 자세히 알아보실 수 있답니다.
https://seowoosung.github.io/CharacterSet/

위 블로그에서 정의한 부분만 살짝 옴겨보면,
character encoding: 문자나 기호들의 집합을 컴퓨터에서 표현하는 방법.(UTF8, UTF16)
character set: 정보를 표현하기 위한 글자들의 집합을 정의한 것. 한 문자 집합을 여러 문자 인코딩에서도 사용가능(ex: 유니코드)

3. Link

(굉장히 조심스럽지만) HATEOAS의 장점 중 한가지는 이후 요청에 대한 URI 정보를 서버에서 알려주고 클라이언트에서는 서버에서 받은 URI를 동적으로 받아서 사용하기 때문에 이후에 URI 정보가 변경되어도 클라이언트에서는 수정이 필요하지 않는 점이 있는데요.

그렇다면 서버에서 다음 URI 정보를 클라이언트에게 알려주어야 하는데, 엄청 간단하게는 ‘response body’에 ‘{ links : … }’ 뭐 이렇게 줄 수도 있겠지만 HTTP1.1에 추가된 Link라는 Header가 이럴때 쓰라고 있는거 같아서 한번 간단하게 테스트 코드를 만들어 보려합니다.

아주 간단하게 nodejs, koa서버를 만들거에요.

기본적인 아이들을 설치해주고

이제 ‘$ node index.js’ 로 서버를 실행시켜주고 index.html 을 브라우저로 실행하고 개발자도구를 켜고 콘솔란을 보면 Link 속성이 딱!

나와야 하는데 나오지 않습니다.. 분명 개발자도구의 네트워크 탭에는 Response Header에 Link 값이 있는데, 클라이언트는 받을 수가 없더라고요.
분명히 CORS도 허용해 주었는데.
그래서 왜 그런지 구글 형, 누나에게서 알아보니.

https://developers.google.com/web/updates/2015/03/introduction-to-fetch#response_types

If a request is made for a resource on another origin which returns the CORs headers, then the type is cors. cors and basic responses are almost identical except that a cors response restricts the headers you can view to ‘Cache-Control’, ‘Content-Language’, ‘Content-Type’, ‘Expires, ‘Last-Modified’, and ‘Pragma’.

CORS로 허용한 통신의 response header 값은 ‘Cache-Control’, ‘Content-Language’, ‘Content-Type’, ‘Expires, ‘Last-Modified’, ‘Pragma’ 로 제한 된다고 하네요.
아.. 뭔가 이상하다 싶어서 스텍오버플로 형, 누나에게 알아보니.

https://stackoverflow.com/questions/43344819/reading-response-headers-with-fetch-api/44816592#44816592

access-control-expose-headers worked for me for headers returned from server …

아하! header에 acces-control-expose-header 값에 Link 값을 허용하면 된다고 합니다.

위와 같이 header에 ‘Access-Control-Expose-Headers’, ‘Link’를 허용해주고 서버를 재실행 후 index.html을 새로고침하면!

header에 link 값이 오는 것을 확인 할 수 있습니다.