Rest API , RESTFul API 정말 많이 들어본 말이다. Web개발자라면 한번 쯤은 들어본 말일거다. 오늘은, 제가 이해한 REST 구조에 대해서 이야기 해보려고 합니다!
REST의 등장배경
REST는 2000년도 Roy fielding의 박사논문에서 나오게 됩니다. Roy Fielding님은 HTTP 1.0 , HTML 명세 등 웹 표준화 작업에 참여한 엄청난 컴퓨터 과학자 분중 한 분 이십니다. Web은 1991년에 처음으로 등장했는데, Web 통신은 HTML로 , URI를 통해서 HTTP로 통신하자고 이미 약속되어있었고, 사용되어지고 있는 상황이었습니다.
따라서, HTTP 1.0을 발표한 상태에서, 이미 웹은 여러 곳에서 사용 중 이었고, Roy Fielding 박사님은 그 당시 대학원생이셨습니다. 이미 사용중인 웹을 망가뜨리면 절대 안됬습니다. 따라서, HTTP 모델을 망가뜨리지 않고 Web을 좀 더 활용할 방법이 없을까는 논문을 낸 것이 "REST구조"입니다.
(대학원생분들 응원합니다)
REST는 아키텍처입니다. 구조입니다.
REST는 웹을 더욱 잘 활용하기 위한 구조입니다. 즉, 어떤 시스템이 REST 구조를 만족한다는 말입니다.
그렇다면 , 우리가 어떤 "구조"를 만족한다는 말은 무슨 말일까요. 이해를 위해 예를 들어 보겠습니다.
현실세계의 예시를 들어볼까요! Software은 보이지 않으니까 , 뜬구름 잡는 소리 같잖아요? 타지마할은 좌우대칭 "구조"를 만족한다고 합니다. 아래의 그림을 보시죠.
어 , 그럼 저희는 알겁니다. "좌우대칭" 그러니까, 중간에 딱 반으로 나누었을 때 ,왼쪽과 오른쪽이 같구나.
즉 , 좌우대칭에 대한 "조건"을 저희는 자연스럽게 생각하게 됩니다. 다른 말로 할게요. 어떤 구조를 만족한다는건, 해당 구조에 대한 "제약조건"을 만족하는 겁니다.
정리하자면
REST는 특정한 "제약조건"을 만족하는 시스템이라는거죠! 그러니까, "REST는 ~~다" 라고 한 마디로 정의하기는 힘들다는 소리입니다. 따라서, REST는 "~~~한 조건들을 만족하는 시스템"을 일일이 다 말하기 힘드니까 , 난 ~~한 제약조건을 만족하는 걸 REST라고 이름 붙일거야! 라고 사람이 정의한거죠!
REST를 만족하는 구조
REST는 여러가지 구조로 이루어진 구조입니다. (재귀함수, 액자식구성 죄송합니다. 근데, 이렇게 표현할 수 밖에 없습니다). 다행히 , HTTP를 사용한다면 , Bold된 4가지는 안지키려고 해도, 지켜집니다. 빨간색은 API에서는 지키기 어렵습니다.
| Client - Server | Stateless | uniform interface |
| layered System | Cache | code-on-demand |
Client - Server
웹서버 - 웹브라우저로 나누어서 웹은 개발되어지고, 관리되어 집니다. C
stateless
HTTP 통신에서는 서버는 클라이언트의 상태를 저장하지 않습니다. 클라이언트가 이전에 했던 요청이 무엇인지에 따라 ,반응이 달라지지 않는다는 이야기입니다. Client에서 자신의 상태를 직접 건네주는 방식으로 HTTP에서는 정의하고 있습니다.
왜 Stateful이 비효율적일까?
보통, 서버는 1대인 서비스도 있겠지만, 여러대의 서버를 운영하는 경우가 많습니다. 그렇다면 , 들어오는 서버에 따라서 , "서버"에서 상태를 기억한다면, 논리적으로는 "하나의 서버"로 묶여져 있지만 물리적으로는 완전히 분리되어있는 쇼핑몰 서버가 , 서로의 상태를 공유해야하는 문제점이 생기게 됩니다.
즉 ,5번 과정처럼 뭘 결제해야하는지 정보를 갖고있는건 결국 서버측이기 때문에, 서버 내에서 추가적인 로직이 소모되고, Client는 1명이 아니라 수백~수천명이 될텐데, 이럴 때마다 서로 공유정보를 찾는 과정 자체가 비효율적입니다.
layered System
- 웬만한 시스템들은 계층적인 구조를 갖게됩니다. 각자의 역할을 서로 분리시켜서, 각자의 일만 하는걸 계층적인 구조라고 합니다.
Cache
- HTTP는 cache 동작을 지원합니다. 따라서, 대부분의 서버는 caching을 하며 , 브라우저에서는 cache 시스템을 갖고 있습니다.
code- on- demand
클라이언트는 리소스에 대한 표현을 응답으로 받고 처리 해야합니다. 네 , JS 입니다.
Uniform interface
Resource에 대한 요청을 통일되고, 한정적으로 수행하는 interface를 가져야합니다. Rest는 "구조"들이 모인 "구조"라고 했습니다. Uniform interface도 구조입니다.
- idenfitication of resources
- 네 , 리소스들을 현재 URI로 식별됩니다.
- manipulation of resources through representations
- 리소스를 요청할 때는, 리소르르 표현하여 응답하라는 이야기인데, 잘 지켜집니다. HTTP header에 Accpect: 뒤에보면 application /json ,인지 text/plain인지, html인지 등등 으로 잘 지켜집니다.
- Self-descripttive Message
- 메세지는 스스로를 설명해야 합니다.
- 즉, "메세지"만으로 , 모든 해석이 가능해야합니다.
- hypermedia as the engine of application state (HATEOAS)
- 애플리케이션의 상태는 하이퍼링크를 통해서 , 전이되어야 한다는 이야기입니다.
- 해당 페이지에 있는 링크에 따라서, 애플리케이션의 흐름이 정해지는 걸 이야기합니다.
왜 uniform interface를 만족시켜야 할까?
Uniform interface를 만족하면, "독립적인 진화"가 가능하게 됩니다. 즉, 서버와 클라이언트가 각각이 독립적으로 진화하게 됩니다. 서버의 기능이 변경되어도 , 클라이언트를 업데이트할 필요가 없어집니다. REST를 만족하는 시스템은 뭐가 있을까요 ? "웹"시스템 자체가 REST를 만족하고 있습니다. HTML은 HTML 자체만으로 모든 내용을 나타냅니다. HATEOAS또한 ,a태그를 통해 만족하게 됩니다.
- 웹 페이지를 변경했다고, 웹 브라우저를 업데이트할 필요가 없어집니다.
- 웹 브라우저를 업데이트 했다고, 웹 페이지를 변경할 필요도 없습니다.
- HTTP 명세가 변경되어도 웹은 잘 동작하게 됩니다.
- HTML 명세가 변경되어도 웹은 잘 동작하게 됩니다.
사실 위의 유연성은 아래의 다양한 기관에서 수많은 개발자와 연구진들의 노력의 결과입니다. 당연한건 컴퓨터 세상에 없습니다. W3C working groups,IETF Working groups,Web browser developer,Web server developer
다음 글에서는 API에 대한 이야기를 하면서, REST API가 뭔지 봅시다!
Refer
'NodeJS' 카테고리의 다른 글
| [REST/API/WEB] REST API에 대해서 (0) | 2022.10.11 |
|---|---|
| [JS/Node/BackEnd] NodeJS에 대한 소개 (0) | 2022.09.22 |