REST, REST API(RESTful API)
REST API를 이제껏 사용하면서, REST란 정확히 무엇이며 왜 REST API를 사용하는지 제대로 이해하지 못하고 사용해왔던거 같다. 예를 들어 HTTP API와의 차이점은 무엇이며, REST API는 어떠한 특징들을 가지는지 정확히 알지 못한다. 그래서 이번에 REST API를 제데로 이해하기 위해서 학습을 진행하였고, 그 내용을 정리 하고자한다.
REST란 무엇인가
시작하기에 앞서 REST란 무엇인가에 대해 제대로 이해 하기위해 여러 사이트를 돌아다니던 도중, NAVER d2에서 '그런 REST API로 괜찮은가'라는 제목의 영상을 접하게 되었다.
해당 영상은 REST에 대한 학습을 하면서 생긴 대부분의 의문들을 해결하는데 아주 큰 도움이 되었고, 다음 내용들은 해당 영상을 참고하여 정리하였다.
REST는 Representational State Transfer의 약어로 2000년도 Roy T.Fielding의 박사학위 논문에 최초로 소개되었다.
이전에 Roy T.Fielding은 HTTP/1.0(1994-1996) 작업에 참여하면서 "How do I improve HTTP without breaking the Web?", 즉 기존에 구축되어있는 WEB을 망치지 않고 HTTP를 발전시키기 위한 방법을 고민하였고 이를 해결하기 위해 고안된 것이 REST이다.
Roy T.Fielding의 논문에 따르면 REST는 분산 하이퍼미디어 시스템(ex Web)을 위한 아키텍처 스타일이라고 정의된다.
즉 "REST는 아키텍처 스타일이며, 아키텍처 스타일은 여러 제약조건들의 집합이다."라고 간단히 설명 할 수 있으면 좋겠지만, 사실 REST는 하이브리드 아키텍처 스타일이라 설명 할 수 있는데, 이는 REST는 아키텍처 스타일이면서, 아키텍처 스타일의 집합이기 때문이다.
REST를 구성하는 스타일
이 단락에선 REST를 구성하는 각 아키텍처 스타일이 무엇을 뜻하며, 어떠한 제약 조건을 가지는지에 초점을 맞추는것 보단 먼저 "REST란 무엇인가"에 대한 근본적인 이해를 위해 특정 스타일과 제약조건에 초점을 맞춰 정리하고자 한다.
REST를 구성하는 스타일은 다음과 같다.
- client-server
- stateless
- cache
- uniform interface
- layered system
- code-on-demand(optional)
영상에선 많은 REST API들이 uniform interface를 만족하지 못하고 있다고 설명하고 있으며, uniform interface는 4가지 제약조건을 가진다.
- identification of resources
- manipulation of resources through representations
- self-descriptive messages
- hypermedia as the engine of application sate(HATEOAS)
4가지 제약조건 중 self-descriptive messages와 hypermedia as the engine of application sate(HATEOAS) 두 가지 제약조건이 대부분의 REST API에서 지켜지지 못하고 있다고 한다.
Self-descriptive message
먼저 Self-descriptive message는 메시지는 스스로를 설명해야한다는 뜻인데, 예를 들면 아래와 같은 메시지는 Self-descriptive message를 만족하지 못한다.
HTTP/1.1 200 OK
Content-Type: application/json
[ { "op": "remove", "path": "a/b/c" } ]왜냐하면 해당 메시지는 Content-Type을 통해 json 형식의 데이터를 포함한다는 것을 알 수 있지만, op, path와 같은 key 값이 무엇을 의미하는지 알 수 없기 때문이다.
HTTP/1.1 200 OK
Content-Type: application/json-patch+json
[ { "op": "remove", "path": "a/b/c" } ]Self-descriptive message를 만족하려면 위와 같이 작성되어야 하는데, Content-Type에 json-patch를 포함했기 때문이다. json-patch의 명세를 찾아가보면 op, path가 무엇을 뜻하는지 알 수 있고, 이는 해당 메시지만으로도 모든 내용을 이해 할 수 있음을 뜻한다.
hypermedia as the engine of application sate(HATEOAS)
HATEOAS는 애플리케이션의 상태는 Hyperlink를 이용해 전이되어야 함을 뜻한다.
예를 들면 글 목록을 출력하는 화면으로의 이동은 GET / articles라는 Hyperlink를 통해 구현가능이 하며, 글 쓰기 및 수정 화면 등 시스템을 구성하는 모든 화면들을 Hyperlink를 통해 따라가며 전이되는 시스템을 구축한다면 이는 HATEOAS를 만족한다고 할 수 있다.
HTTP/1.1 200 OK
Content-Type: text/html
<html>
<head></head>
<body><a href="/test"></a></body>
</html>위와 같은 HTML 메시지는 a태그의 Hyperlink를 통해 전이되고 있기 때문에 HATEOAS라고 할 수 있다.
위 두가지 제약조건에 대한 이해는 했으나, 과연 웹이 아닌 앱 환경의 클라이언트에서도 해당 제약조건들을 만족하는 REST API가 앱의 특성을 고려한다면 큰 도움이 되는지는 잘 모르겠다는 느낌이다.. 그래서 이에 대한 부분은 글 마지막에 정리하고자 한다.
왜 Uniform Interface?
Uniform Interface의 목적은 다음과 같다.
- 서버와 클라이언트가 각각 독립적으로 진화한다.
- 서버의 기능이 변경되어도 클라이언트를 업데이트할 필요가 없다.
현재 웹은 웹페이지를 변경했다고 웹 브라우저를 업데이트 할 필요가 없으며, 웹 브라우저를 업데이트했다고 웹 페이지를 변경할 필요도 없다.
심지어 HTTP, HTML 명세가 변경되어도 웹은 잘 동작한다.
이러한 점에서 Uniform Interface는 "How do I improve HTTP without breaking the Web?"에 대한 해답이 되었다고 볼 수 있다.
하지만 이를 만족하는 REST API라도 웹이아닌 앱 환경, 예를 들면 Android의 경우에는 서비스가 대폭 변경이 된다면 클라이언트의 업데이트는 거의 필연적이라고 생각한다.
분명 앱 업데이트 주기를 늦출 수 있겠지만, 결국 저 목적에 완벽히 부합하지는 못한다고 생각한다.
그렇다면 앱에서는?
앱 개발자의 입장에서 봤을 때, 웹은 HTML을 이용하면 해당 각 태그들에 대한 상세한 설명이 있어 화면을 그려내는것이 가능하고, Hyperlink를 이용해 HATEOAS를 만족할 수 있다.
하지만 앱에서는 앱 마다 구현하는 방식이 다르며, 현재 대부분이 자신의 시스템에 맞는 API 명세를 작성하여 사용하는 것으로 Self-descriptive message를 대신한다.
그리고 HATEOAS역시 Android, iOS에서는 메시지에 링크를 포함하여 구현 할 수는 있지만 그러한 방식으로 구현된 REST API가 의미 있는지는 모르겠다..
Roy T.Fielding이 말하는 REST에 완벽히 부합하는 REST API가 무조건 정답일까..
REST를 이해하기 위해 여러 제약조건과 특징에 대해 학습을 해보았다. Roy T.Fielding이 말하는 REST 무엇인지 어느정도 이해는 되지만, 완벽히 이해하려면 좀 더 깊게 학습할 필요가 있기에 여기서 마무리 하려고한다. 결국 무조건 Roy T.Fielding이 말하는 REST에 완벽히 부합하는 REST API를 구현하기보다, 상황에 맞게 시스템의 특성을 고려하여 어느정도 부분은 타협하여 만드는 것도 하나의 방법이라고 생각한다.
