REST구조에 대해서는 설명이 끝났으니, REST를 만족하는 API에 대한 설명으로 REST에 대한건 마치려고 합니다!
먼저, API에 대해서부터 알아보죠!
API
API는 Program과 소통하기 위한 모듈, 혹은 함수를 이야기합니다. 현실세계에서 예시를 들면, 식당을 예시로 많이들게 됩니다. 주방장이 Server , 점원(홀)이 API , 손님이 Client라고 예시를 많이듭니다. 하지만, "Program과 소통하기 위한 함수"
라고 정의하고 싶습니다. 왜냐하면, 프로그램끼리 소통을 하기위해서 API를 쓰기 때문이죠. 단순히 client가 server에 요청하는 형태의 API뿐만아니라, Program과 Program 혹은 Program과 유저가 소통하기 위해서 만들어놓은 별도의 로직, 함수라고 정의할 수 있을 것 같습니다.
웹통신
웹통신은 HTTP를 이용해서 브라우저와 서버 사이에 일어나는 통신입니다. Server-client 모델을 이용하고 있고, HTML을 주는 방식이죠 .
API 통신과 웹 통신, 혼동하지말자!
이전 글에서 웹은 REST구조를 만족한다고 이야기 했습니다. 웹은 "HTML"을 교환하기 때문에, HTML 명세는 정해져있으므로, HTML은 self descriptive하면서 , a 태그를 이용하여 HATEOAS를 만족하게 됩니다.
하지만, API를 이용한 통신은 HTML 파일을 주고받지 않고, JSON파일을 주고받습니다. 즉, REST하게 짜기 어렵다는 이야기죠! 그럼 , REST하게 짤려면 JSON을 REST하게 만들면 되는겁니다.
REST API
JSON은 Hyperlink 기능도 없고, self-descriptive 하다고 하기에는 애매합니다. HTML을 주고 받을 때와 , JSON을 주고받을 때의 차이점을 보시죠.
HTML
1. 응답 메세지의 Content -Type을 보고 , media Type이 html임을 확인한다.
2. HTTP 명세에 media type은 IANA에 등록되어있다고 하므로, IANA에서 text/html의 설명을 찾는다.
3. IANA에 따르면, text/html의 명세가 등록되어 있고,해당 링크를 찾아가서 명세를 해석합니다.
4. 명세를 보고 , HTML의 모든 메세지를 해석할 수 있습니다.
JSON
1. 응답 메세지의 Content -Type을 보고 , media Type이 JSON임을 확인한다.
2. HTTP 명세에 media type은 IANA에 등록되어있다고 하므로, IANA에서 application/json의 설명을 찾는다.
3. IANA에 따르면, application/json의 명세가 등록되어 있고,해당 링크를 찾아가서 명세를 해석합니다.
4. json 문서를 성공적으로 파싱한다. 하지만, id와 title이 무슨 의미를 담고 있는지는 알 방법이 없다.
=> self -descriptive하지 않습니다.
다시한번 이야기하면, Self descriptive하다는 이야기는, 메세지만으로 해석이 가능하다는 이야기이고, 이건 즉, 서버가 바뀌어도 상관없다는 이야기입니다. 모바일로 접속해도 메세지만 똑바로 생성해서주면 , 상관이 없습니다. 서버가 바뀌어도 , message만 잘 생성해준다면 상관없습니다. 시간이 지나서 좋은 서버가 나오면, 서버를 얼마든지 업데이트 할 수 있게 되는거죠!
HATEOAS하다는 이야기는 링크는 동적으로 바뀔 수 있다는 이야기 입니다. 즉, 서버에서 링크를 바꾸어도, 클라이언트는 바뀐 링크로 그냥 찾아가면 되지, 어디로 전이가 가능한지 미리 알고있지 않다는 이야기 입니다
. 슈뢰딩거의 고양이..? 보기전까지는 살아있따?
2개가 만족되면 왜, 서버와 클라이언트가 독립적으로 진화할 수 있었는지 이해가 가시나요!
JSON Self-descriptive처리
media type 등록하기
IANA에 Media type으로 등록을 합니다.
1. 미디어 타입을 하나 정의한다.
2. 미디어 타입 문서를 작성한 뒤, IANA에 등록을 합니다.
3. 이제 이 명세는 등록되어 있으므로,IANA를 통해서 찾아갈 수 있다.
단점 : 번거롭습니다.
Profile 방식
Link헤더에 profile을 relation으로 등록하여, 명세를 링크할 수 있습니다.
Link : <명세주소> ; rel = "profile" 이런식으로 헤더에 쓸 수 있습니다.
단점: 브라우저가 Link 헤더 (RFC 5988)와 profile(RFC 6906)을 이해해야합니다.
JSON HATEOAS 처리
1. 그냥 data에 link를 넣습니다. link처리를 추가적으로 따로 해야합니다.
2. JSON으로 하이퍼링크를 표현하는 방법을 정의한 명세들을 활용하면 됩니다. (siren,UBER,JSON API 등등 , 하지만, 기존 API를 많이 고쳐야합니다)
3. HTTP 헤더로 Location,Link 등으로 표현해서 넘겨주면 됩니다.
보통, data & header를 합쳐서 적절하게 표현한다고 합니다.
위의 방법들은 사실 잘 모르겠습니다. Node JS로 API를 구현할 때, 직접 적용해보면서 해봐야할것 같습니다.
REST API에 대한 오해
REST를 무조건 써야하나 ? X 입니다. REST한 API는 오히려 세상에 거의 없다고 합니다. 그래서, 사실 REST API라고 불리는 것들은 REST API가 아닙니다. 결국 선택사항이라는 이야기 입니다. 하지만, REST는 긴 시간에 걸쳐 진화하는 어플리케이션을 설계하기 위한 기법입니다. "유지보수"는 필수적인 요소이기 때문에, 결국 REST한 구조로 API들을 짜는게 좋겠죠!
Refer
'NodeJS' 카테고리의 다른 글
| [REST/WEB/구조] Rest구조에 대해서 (1) | 2022.10.11 |
|---|---|
| [JS/Node/BackEnd] NodeJS에 대한 소개 (0) | 2022.09.22 |