시청한 영상 : 유튜브 naver d2 채널의 그런 REST api로 괜찮은가?
기본적으로 REST api가 무엇인지에 대해선 다루지 않겠다.
이미 수도 없이 많은 좋은 글 들이 존재한다.
대표적으로 이 글 처럼 말이다.
이 영상에서 짚는 핵심은 그래서
우리가 REST api, 혹은 RESTful 하다고 부르는 api들이
정말 모든 REST 규칙을 제대로 만족하고 있는가? 이다.
대부분의 경우에는 그렇지 않다.
왜냐하면, 대부분이 self descriptiveness와 HATEOAS를 만족하지 않기 때문이다.
self descriptiveness는 자체 표현 구조이다.
REST api는 api 그 자체로 자신이 어떤 data인지 표현해야 한다는 뜻이다.
이 api의 source는 어디이며, 어떤 content-type인지 명확하게 표시해야 하고, 또한 내가 응답한 JSON 데이터의 key : value가 뭘 의미하는지도 즉시 알 수 있게 해야 하는 것이다.
예를 들면 이런 식이다.
GET /posts HTTP/1.1
HOST: example.org //이런 식으로 host가 어딘지 표현해야 함
HTTP/1.1 200 OK
Content-type: application/vnd.exam+json
//이렇게 이 api가 어떤 방식으로 적혔고, 어떻게 해석되는지 표현해야함 IANA에 미리 등록된 type이어야 함.
{
....
}
HATEOAS는 Hypermedia As The Engine of Application State 라는 뜻이다. 이 말의 뜻은 하이퍼미디어를 통한 상태의 전이가 가능해야 한다 라는 뜻 이다.
이게 무슨 말이냐면, api가 다음 상태로 전이될 수 있게 링크가 필요하다는 말인데, 한마디로 이런 식이다.
{
{
"link" : "https://www.example.org/data/1",
"data" : "data1"
},
{
"link" : "https://www.example.org/data/2",
"data" : "data2"
}
}대략 이런 식으로, 링크가 필요하다는 말이다.
사실 나도 그렇고, 대부분 자신이 REST api를 구현했다고 생각하는 사람들은 이런 식으로 하지 않았을 것이라 생각한다.
강의를 듣다보면 사실 이것은 이 방식을 무-조건 따라서 REST api를 만들어라. 라기 보다는, 그냥 이렇게 해야 REST api 인거고, 그게 아니면 그냥 HTTP api 라던지 다른 방식으로 명명하자. 정도의 뉘앙스를 받았다.
아마 실제로 RESTful API를 구현하는 개발자를 뽑는다는 회사들도, 저렇게 완벽하게 REST를 구현한 api를 의미하는것은 아닐 것이라고 생각한다.
하지만, 일단은 알고 넘어가려고 한다.
