서론
백엔들 개발자라면 누구나 한 번쯤은 본 유명한 발표자료입니다.
발표에서의 핵심내용은 아래와 같습니다.
오늘날 대부분의 "REST API"는 사실 REST를 따르지 않고 있다.
REST의 제약조건을 만족하지 않고 있기 때문이다.
해당 발표로, 우리가 잘못 알고있는 상식들을 바로잡는데 크게 기여했다고 생각합니다.
그러나 아직까지도 각종 블로그 포스팅글에 REST, RESTful, REST API, RESTful API 등의 용어들이 마치 웹 서비스용 API 라는 하나의 뜻으로 정의되어 남용 및 혼용되는 경우를 많이 봅니다.
뭐, 대충 뜻만 통하면 되는거 아닌가...? 라고 생각이 들다가도,
REST의 창시자인 Roy Fielding이 개인 블로그를 통해, REST API라 불리는 것들이 REST 규약을 위반하고 있으니, 규약을 지키거나 다른 단어를 선택하라고 말합니다.
고로 창시자의 뜻을 이어받아, 우리가 알고있는 REST에 대한 잘못된 상식 이를 바로 잡기위한 글을 써보려고 합니다.
레츠고!
대표적인 오해 6가지
1. REST는 웹 서비스 API 정의를 위한 아키텍처이다.
REST는 웹 서비스 API를 정의할 때 이해하기 쉽고 사용하기 쉬운 URL을 만드는 규칙이 아닙니다.
놀랍게도 REST의 개념이 처음 등장한 Roy Fielding의 논문은 2000년에 출간되었고, 이 시대에는 우리가 흔히 알고있는 웹 서비스 API가 존재하지 않았습니다.
Roy Fielding은 HTTP/1.0 (1991~1995), HTTP/1.1 (1995~1999)의 주요 저자 중 한명이고,
수십 년의 변화를 견딜 수 있고, 독립적으로 진화하는 시스템을 만들기 위해 REST를 설계했다고 합니다.
자세한 내용은 인터뷰를 통해 확인할 수 있습니다.
REST의 정확한 정의는 분산형 하이퍼미디어 시스템을 위한 아키텍처 스타일이라고 논문에 나와있습니다. REST 아키텍처가 잘 적용된 대표적인 예시는, 우리 모두가 잘 알고있는 웹사이트 입니다.
2. REST는 HTTP 표준을 기반으로 구현한다.
REST는 어떤 구현체가 아니라, 아키텍처 스타일입니다. 그리고 REST는 특정 네트워크 프로토콜에 국한되지 않습니다.
물론 REST가 HTTP 문제점을 해결하기 위해 만든 아키텍처이고, 실제로 REST의 규약들은 웹 환경에 최적화 되어있습니다. 그러나 웹은 REST 스타일 아키텍처가 잘 적용된 하나의 예시이고, 핵심은 분산 하이퍼 미디어 시스템에 있다고 논문 일부에 설명되어있습니다.
The modern Web is one instance of a REST-style architecture. Although Web-based
applications can include access to other styles of interaction, the central focus of its
protocol and performance concerns is distributed hypermedia
3. REST는 HTTP 프로토콜을 활용하는 아키텍처이다.
2번과 비슷한 내용입니다. REST는 프로토콜과 관련이 없는 아키텍처이지만, 제약조건 때문에 헷갈릴 수 있습니다.
REST의 제약조건을 살펴보면 아래와 같습니다.
- Client–server architecture
- Statelessness
- Cacheability
- Layered system
- Code on demand (optional)
- Uniform interface
HTTP에 대해 공부를 하신 분들이라면 이거 HTTP에 대한 내용이 아닌가? 라는 생각이 드실텐데, 그 이유가 바로 HTTP는 REST 아키텍처 스타일이 반영된 프로토콜이기 때문입니다.
REST는 HTTP/1.0 → HTTP/1.1로 넘어오면서 반영됐습니다.
HTTP와 REST의 관계?
그렇다고해서 HTTP가 REST라는 이야기가 아닙니다. HTTP는 REST 아키텍처 스타일이 반영되었기 때문에, HTTP를 이용하여 REST 제약조건이 잘 지켜진 RESTful 시스템을 쉽게 만들 수 있다는 것이 핵심입니다.
다른 네트워크 프로토콜을 이용하여 REST 아키텍처를 따르는 시스템을 만든다면 그 또한 RESTful 시스템입니다.
4. REST와 RESTful은 같은 말이다.
RESTful은 공식적인 단어도, REST의 창시자가 만든 단어도 아닙니다. (논문에 RESTful이란 단어는 등장하지 않습니다.)
다만, REST의 제약조건을 모두 따르는 시스템을 RESTful, 혹은 RESTful 시스템이라고 전 세계적으로 무언의 약속을 한 것같습니다.
앞에서도 언급한
웹사이트는 REST의 제약조건을 모두 따르기 때문에 RESTful 이라 할 수 있습니다.
5. REST API는 HTTP 메서드를 사용하여 검색, 생성, 업데이트, 삭제한다.
반복하지만 REST는 특정 네트워크 프로토콜에 국한되는 개념이 아닙니다.
REST API는 REST의 제약조건을 따르는 API 이다. 정도로 나타낼 수 있고, HTTP 메서드를 사용하여 검색, 생성, 업데이트, 삭제한다. 라는 내용은 단순히 HTTP RPC의 일부입니다.
6. /customer 또는 /cusrtomer/1과 같은 리소스에 대해 알기쉬운 URL를 정의하는 것이 REST 제약 조건에 해당하며 RESTful API라 부른다.
REST와 관련이 없는 내용입니다. 아마 이런 내용이 널리 퍼지게된 이유 중 하나가 마이크로소프트 REST API 가이드 라인 때문이지 않을까 싶네요.
7장에 아래와 같은 내용이 있습니다.
인간은 URL을 쉽게 읽고 구성할 수 있어야 한다.
REST 가이드 라인에 이런 내용이 있으니, 해당 내용이 REST의 제약 조건이라고 착각하게 만들었나봅니다.
REST를 이해하기 어려운 이유
1. REST라는 단어가 남용되고 있다.
우리가 처음 접하게 되는 REST API, RESTful API라는 용어는 대부분 웹 서비스 API 정의를 위한 아키텍처 정도로 생각합니다.
수 많은 블로그에 나와있는 내용들을 보면서, REST는 HTTP 메소드와 알기 쉬운 URL을 통해 쉽고 편하게 사용할 수 있는 사용자 API를 만들기 위한 아키텍처 혹은 제약사항 정도로 이해하게 됩니다.
2. REST라는 단어를 직역하여 이해하려고 한다.
REST는 Representational state transfer의 줄임말이며, 번역기나 사전을 통해 직역하면 대표 상태 이전 혹은 표현 상태 이전 인데, REST의 제약사항을 보았을때 표현 상태 전송이 더 어울리는것 같습니다.
REST를 웹 서비스 API 정의를 위한 아키텍처로 알고있는 상태에서 REST의 풀네임의 직역 및 정의를 읽게되다면 서로 매칭이 안되니까, 무슨 말인지 이해못하는게 당연하지 않나 생각됩니다.
3. REST를 잘 모르는 상태에서 REST 제약조건을 이해하려고 한다.
이것도 비슷한 내용인데, REST의 6가지 제약조건이 있습니다.
- Client–server architecture
- Statelessness
- Cacheability
- Layered system
- Code on demand (optional)
- Uniform interface
이 위의 제약조건들은 API 개발을 위한 것이 아닙니다.
REST는 왜 만들어졌는가?
REST를 왜 만들었는지 그 의도와 해결하기 위한 고민을 알게되면 이해하기 쉽습니다.
Roy Fielding은 수십 년의 변화를 견딜 수 있는 시스템을 만들고 싶어 하였고, 그 시스템을 만들기 위해 끊임없는 질문과 고민을 하였습니다.
- 웹을 손상시키지 않고 HTTP를 어떻게 발전시킬 수 있을까?
- 시대가 바뀌면서 확장성 및 일관성 문제는 어떻게 해결할 수 있을까?
- Web과 같은 분산 하이퍼미디어 시스템이 생겨난다면 서로 어떻게 연결해야 할까?
이런 고민끝에 만들어진게 REST이고, REST가 반영된 프로토콜이 HTTP이며, 웹은 HTTP를 통해 통신합니다.
REST가 없었다면 현재의 안드로이드 및 IOS 앱처럼 각 웹사이트마다 서로 다른 설치 프로그램이 필요하다거나 서버의 변경사항이 있으면 업데이트 후 접속하게 됐을겁니다. 아니면 각 웹사이트별로 접속하기 위한 수 많은 전용 브라우저가 만들어 졌을수도 있습니다.
그러나 우리는 REST 덕분에 브라우저 버젼과 종류에 상관없이 80~90년대에 만들어진 웹사이트에 접속할 수 있습니다.
수십 년의 변화를 견딜 수 있는 시스템 이것이 REST가 추구하는 방향입니다.
REST를 꼭 알아야할까?
Roy Fielding의 PPT 발표 자료 마지막에 나와있습니다.
시스템 전체를 제어할 수 있다고 생각하거나, 진화에 관심이 없다면, REST에 대해 논쟁하는 데 시간을 낭비하지 마세요.
라고 합니다.
진정한 REST API에 대해 알고싶다.
Roy Fielding 개인 블로그 글 (REST API는 하이퍼텍스트 기반이어야 합니다.)
을 통해 사람들이 자주 위반하는 룰 6가지 정도를 설명합니다.
그리고 REST, REST API, RESTful API에 관한 사람들의 질문에 대한 답글 또한 최대한 길게 풀어서 설명합니다.
제가 설명하는것 보단, 해당 글을 번역해서 쭉 읽는게 훨씬 더 도움이 될 것 같습니다.
결론
공부하면서 REST가 무엇인지 정확하게 알게되었습니다.
API를 개발하고 구현하는데, REST는 크게 상관 없는 단어라는 것을 알게되었습니다.
그리고 수 십년을 내다본 Roy Fielding이란 인물을 매우 존경하게 되었습니다.
[참고]
https://www.infoq.com/articles/roy-fielding-on-versioning/
https://deview.kr/2017/schedule/212
http://slides.com/eungjun/rest#/69
https://twobithistory.org/2020/06/28/rest.html#fnref:6
https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation_2up.pdf
https://stackoverflow.com/questions/2190836/what-is-the-difference-between-http-and-rest
https://news.ycombinator.com/item?id=7201871
https://en.wikipedia.org/wiki/Representational_state_transfer
https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
https://shoark7.github.io/programming/knowledge/what-is-rest
