REST API

REST API란

REST API, REST API 많이들 들어봤을 것이다.

면접 질문에도 단골로 나오기도 하고, 많은 개발자들이 오해하고 사용하고 있는 기술이기도 하다.

오늘은 REST API가 무엇인지 살펴보도록하자.

REST는 REpresentational State Transfer의 약자로 네트워크 아키텍처를 의미한다.

등장의 목적은 시스템 각각의 독립적인 진화를 보장하기 위해 등장했다.

오늘 날 많은 개발자들이 REST API를 잘못 사용하고 있으며 이는 REST API라고 볼 수 없다. (정말?)

그 이유는 REST 아키텍처 스타일을 따라야하는데, 아래와 같다.

재밌는 점은 Uniform Interface를 제외한 나머지 특성들은 HTTP 프로토콜을 사용하면 자연스럽게 지킬 수 있는 규약인 반면 Uniform Interface만큼은 REST API를 상징하는 특징이라고 할 수 있다.

여기서 Uniform Interface를 구성하는 아래 네 가지 요소를 만족해야한다.

identification of resources - 자원의 독립
- e.q. 자원이 URL에 표현되어야한다.
manipulation of resources through representation - 표현을 통한 자원의 조작
- e.q. POST,PUT,DELETE 등과 같은 메소드로 자원을 조작할 수 있어야 한다.

그리고 여기서 부터 가장 많은 개발자들이 REST API의 규약을 지키지 못하는 두 가지 이유가 등장한다.

self-descrive message
- 우리는 메시지만 보더라도 해당 API가 어떤 동작을 하는지 이해할 수 있어야 한다.
- 서버가 변해도 메시지는 그 메시지를 보고 해석할 수 있어야한다
- 확장 가능한 커뮤니케이션
hypermisa as the engine of application state (HATEOAS)
- 하이퍼 미디어(링크)를 통해 애플리케이션 상태 전이가 가능해야한다.
- 링크 정보를 동적으로 바꿀 수 있다. (Versioning X)

즉 많은 개발자들이 self-descrive message과 HATEOAS를 지키지 않아 REST API의 규약을 어기고 있다고 한다.

그럼 이 두 가지를 지키기 위해서 우리는 무엇을 해야할까?

self-descrive message의 경우 두 가지 방법이 존재한다.

미디어 타입을 정의하여 IANA(미디어 타입, MIME 타입, 콘텐츠 타입을 관리하는 국제 표준기구)에 등록해두고 그 미디어 타입을 리소스를 반환할 때 Content-Type으로 사용한다.
profile 헤더 링크를 추가한다.

HATEOAS의 경우 다음 상태로 전이할 수 있는 URL 링크를 응답에 포함시킨다

결론은 크게 문제는 없다이다.

REST API의 기준에 대한 정의가 전 세계 조직, 단체, 국가마다 조금씩 다르다.

REST API를 만든 로이 필딩이 박사 논문에서 언급한 위의 내용들을 지키지 않더라도 절대 다수가 이해할 수 있을 만한 수준에서 REST API라고 사용하는 집단 또한 많다.

가장 대표적으로 MicroSoft가 있는데, 이곳의 경우 REST API의 정의를 자원과 행위를 중심으로 표현하는 아키텍처로써만 REST API를 정의하고 있다.

이는 실제로 많은 국내 기업, 팀에서 REST API를 적용하는 기법이기도 하다.

물론 이를 본 로이 필딩이 아 REST API 그렇게 쓰는거 아닌데.. 쓰읍…이라고 해도 사실 크게 문제는 되지 않는다.

실제로 우리 팀 또한 git-flow라는 브랜치 전략을 사용하지만 철저하게 git-flow를 따르기 보다는 상황에 맞게 유연하게 변형된 git-flow 정책을 사용하고 있다.

결국 기술이나 정의는 사용하기 나름이며 유연하게 정의하고 팀원들이 납득할 수 있을 만한 방향으로만 쓴다면 크게 문제는 없지 않나 싶은 생각이다.

인프런 백기선님의 Spring REST API

그런 REST API로 괜찮은가? - naver d2