[웹] REST

웹 개발을 하다보면 REST API  개발에 대해 들어본 적이 있을 것이다.

나 역시 졸업 프로젝트로 웹 사이트를 만들 때 많은 구글링을 했었는데,

REST API라는 용어를 자주 보았다.

마침 REST에 대한 좋은 영상을 접하게 되어서, 내용을 정리해보고자 한다.

 

1. REST란?

개발을 공부하다 보면 참 많은 약어가 등장한다. 

개인적으로 이러한 약어를 풀어서 알고있는 것이 생각보다 공부하는데에 큰 도움이 되는 것 같다.

REST라는 약어는 REpresentational State Transfer의 약자이다. (표현 상태 전송?.....)

표현 상태 전송이라고 직역한 이 REST는 한마디로 정의하기가 참 모호하다. 

 

REST를 더 잘 이해하기 위해서 WEB의 역사를 조금 알 필요가 있었다.

문제는 '어떻게 인터넷에서 정보를 공유할 것인가?'에서 시작되었다고 한다.

이 문제에 대한 해답은 '모든 정보들을 하이퍼텍스트로 연결한다' 였다.

이때 표현 형식이 HTML, 식별자가 URI, 전송방법이 HTTP로 정해진 것이다.

HTTP/1.0을 기반으로 수많은 웹서버가 탄생하였고, 사용되었다. 그 시점에서 로이필딩은 이미 만들어진 웹 생태계를 방해하지 않으면서 HTTP를 진보시킬 방법에 대해 고민하게 된다. 그 해답으로 로이필딩은 2000년에 발표한 박사 학위 논문에서 REST를 처음 소개하게 된다.

REST를 만든 로이필딩에 의하면 REST는 분산 하이퍼미디어 시스템을 위한 아키텍쳐 스타일로 정의가 된다.

즉, REST는 웹 생태계에서 더 향상된 정보 공유 방법을 찾다가 탄생하게 된 아키텍쳐 스타일이다.

 

+ 들은대로 정리를 하긴 했지만 다시 봐도 이해하기 힘든 내용들이라고 생각하던 중, 좀 더 이해를 도와주는 글을 찾게되어 내용을 추가하게 되었다. 내가 착각하고 있던 것은 REST가 리소스를 주고받는다고 생각했던 것이다. REST는 말그대로 상태를 나타내주는 아키텍쳐 스타일이다. 원본 데이터에 접근하여 정보를 가져오는 것이 아니라, 그 정보를 읽어온 다음 적당한 상태로 표현해주는 것이다. 

2. REST API ?

REST API는 REST 아키텍쳐 스타일을 따르는 API라고 할 수 있다. 

REST자체가 아키텍쳐 스타일이고, 이것은 달리 말해 제약조건의 집합이라고 표현된다.

즉, REST API라고 부르기 위해서는 이 제약조건을 모두 만족시켜야 하는 것이다.

실제로 대부분의 사람들이 REST를 만족시켰다고 받아들였던 여러 시스템에 대해 로이필딩은 그것이  REST가 아니라고 한 사례가 여럿 존재한다. 이것은 단순히 REST의 성질을 띄고있다고해서 REST API라고 할 수는 없다는 것이다.

 

REST API가 되기 위한 REST의 제약조건을 6가지로 표현하자면 아래와 같다.

• client-server
• stateless
• cache
• uniform interface
• layered system
• code-on-demand (optional)

오늘날에는 HTTP의 규칙만 잘 따라 주어도 위의 대부분의 조건들을 만족시킬 수 있다.

다만, uniform interface만큼은 잘 지켜지기가 힘들다고 한다.

uniform inteface는 다시 4가지의 제약조건으로 나누어질 수 있다.

• identification of resources (리소스가 URI로 식별되야한다.)
• manipulation of resources through representations (representation(HTTP 메소드)의 전송을 통해 리소스를 조작해야한다.)
• self-descriptive messages 
• hypermedia as the engine of application state

위의 네가지중 위의 두가지는 대부분 잘 지켜지고 있지만, 놀랍게도 자칭 REST하다고 불리는 대부분의 곳에서 아래의 두가지 조건은 만족하지 못하고 있다고 한다. 이 사실만으로도 아래의 두 가지가 REST API로 인정받기 위해 key point가 된다고 할 수 있겠다.

자세히 이해하지는 못했지만 먼저 self-descriptive message는 메시지가 스스로를 완벽히 설명해야 한다는 조건이다.

예를들어 GET / HTTP/1.1 이라는 요청메시지는 목적지가 적혀있지 않으므로 이 조건을 만족하지 않는다.

이것이 self-descriptive하려면 Host : www.naver.com  처럼 요청메시지의 목적지가 추가되어야한다.

hypermedia as the engine of applicaion state 조건은 애플리케이션의 상태가 반드시 HyperLink를 이용해 전이되어야한다는 조건이다.

html을 예시로 들자면 <a>태그를 통해 하이퍼링크가 표현되고 그 링크를 통해 상태가 전이될 수 있다. 따라서 html을 이용하여 네번째 조건을 만족할 수 있는 것이다.

 

위의 조건들을 아직 완벽하게 이해하기는 어려웠지만, REST API라고 부르기 위해선 단 하나의 조건도 어긋나면 안된다는 점을 알게 되었다.

그렇다면 왜 이렇게 위와 같은 Uniform Interface를 반드시 지켜주어야 할까?

REST를 만들게 된 계기가 이미 형성된 웹 생태계를 해치지 않으면서 HTTP를 발전시키는 것이라고 했다.

이것이 가능하기 위해서는 서버와 클라이언트가 각각 독립적으로 진화될 수 있어야 한다.

즉, 서버의 기능이 변경되어도 클라이언트를 업데이트할 필요가 없어야 한다는 것이다. 그리고 이것이 만족되기 위해서는 결국 위의 네가지 조건이 만족되어야 하므로, Uniform Interface의 조건중 하나라도 만족하지 못한다면 REST라고 할 수 없게 되는 것이다.

 

웹이라는 예시를 통해 위의 복잡한 내용을 이해할 수 있었다.

웹은 웹 페이지를 변경했다고 해서 웹 브라우저를 업데이트 할 필요는 없다.

반대로, 웹 브라우저를 업데이트 했다고 해서 웹 페이지를 변경할 필요도 없다.

또한 HTTP 명세가 변경되어도 웹은 잘 동작하고, HTML명세가 변경되어도 웹은 잘 동작한다.

이렇듯, 웹은 REST를 참 잘 만족하고 있다. (모바일 앱을 생각해보면 잘 만족하지 못하고 있다는 것을 알 수 있다.)

 

+ RESTful API란 HTTP API에서 사용되는 REST가 단지 리소스가 표현된 상태만을 의미하므로, 어떠한 '행위'에 대해서 이야기하고 있지 않은 점을 HTTP 메소드와 URI를 활용하여 보완한 API라고 할 수 있겠다. 그래서 RESTful API에서는 REST 아키텍쳐를 통해 표현된 리소스와 더불어 어떠한 행위를 명시할 수 있는 HTTP 메소드와 URI를 활용하게 된다.

REST - 리소스가 어떻게 표현되는지

URI - 어떤 리소스인지

HTTP 메소드 - 어떤 행위인지

 

3. 그래서...

관련된 강연을 들으며 REST가 무엇인지 감을 잡을 수 있었다.

웹이 REST를 아주 잘 따르고있으며, 오늘날 REST API라고 불리는 것들은 사실 REST하지 않은 경우가 대부분인 것 또한 알았다.

누구든 경험해 보았을 것이다.. 머리에 무언가 들어왔지만 그게 무엇인지 말해보라고 하면 아무말도 할 수 없을 때...

분명 많은 깨달음을 얻었지만 역시 실습없는 이론주입은 이해의 한계가 있는 것 같다.

'그런 REST API로 괜찮은가'라는 키워드를 통해 검색해보면 정말 좋은 강연이 있다. 

두고두고 보면서 깨달은 점을 계속해서 업데이트 해나가야 할 글이 된 것 같다. 

 

+ 현업에서 일하고 계신 분께서 RESTful API에 관심을 갖는 이유가 명확한 API를 정의하는 방법이기 때문이라고 말씀하신 것을 보고, 나 또한 더욱 관심을 갖게 된것 같다. 엔드포인트만 보고도 어떤 동작을 하는 API인지 바로 이해할 수 있게 하는 하나의 방식이 될 수 있기 때문이라고 한다. 평소 관심이 많은 클린코드 작성과도 일맥상통한 이유라고 할 수 있겠다.