[스크랩] REST 알아보기 - 2부, 웹에서 뭐가 그리도 좋을까?

출처 : http://dreamgoer.net/200

이 글은 REST에 대해 정리하는 두편의 글중 두번째 글입니다. 따라서 1부("REST 알아보기 - 1부, 연동의 역사", 클릭)를 읽지 않으신 분은 먼저 1부부터 보시고 본 글을 읽어주시길 바랍니다. 1부 글은 왠만하면 반복하지 않을테니까 말입니다. 

[1부를 아주 간단히 요약해버리자면]

REST도 네트웍에 물려있는 서비스 자원들간의 연동이라는 이슈에서 나온 것으로써, 1부에서 네트웍에서 연동의 역사를 한번 나름대로 짚어보았습니다. RPC - CORBA - RMI - SOAP - REST에 이르기까지, 그 기술들이 진화하며 해결한 부분들을 파악했습니다. 

REST는 "Representaional State Transfer"의 약자로써, 웹프로토콜(HTTP)을 활용하여, Resource 중심으로 연동 인터페이스를 정의하고 사용하는 방법을 제안한 것입니다. 한마디로 웹(HTTP) 프로토콜을 최대한 그대로 사용하여, Open API를 만드는 스타일가이드라고 할 수 있습니다. 

그러나, 이런 개념적인 얘기로는 개발자가 아니신 분들이라면 잘 이해가 가지 않을 것입니다. 그래서 오늘은 좀 더 명확하게 이해할 수 있도록 REST가 좋은 이유를 구체적으로 설명하도록 하겠습니다. 

 

[REST는 뭐가 그리 좋은가?]

1. 웹친화적이다.

이미 웹 친화적이라는 말씀은 서두에서 드렸으므로, 더이상 설명할 필요는 없을 것 같습니다. 요새는 방화벽을 넘어서 연동해야 하는 경우가 허다합니다. 그럴때 SOAP이나 REST를 제외한 다른 연동프로토콜들을 대부분 방화벽에서 문제를 야기합니다. 

(출처: http://olivecentre.org.uk)

2. 웹서버로 해결이 가능하다

REST는 HTTP 동사를 그대로 사용합니다. 앞서서 얘기했듯이 HTTP request, response 전부 재활용합니다. 심지어 Error 상태 code까지도 말입니다. 게다가 결과를 주고받는 것도 웹브라우저에서 지원되는 XML 또는 JSON입니다. (JSON은 자바스크립트에서 XML보다 데이타를 쉽게 전달하는 방법이지요) 따라서 대부분의 서버프로그램을 제외하면 REST를 운용할 수 있는환경이 웹서버하나로 해결되는 셈입니다. (참고로 요새 공유기, IP전화기, 각종 셋탑 등 모든 IP장비는 웹을 통해 설정을 할 수 있게 되어 있습니다. 그 얘기는 그런 장비들에 웹서버들이 모두 들어간다는 것입니다.)

(출처: http://www.symbian-freeware.com)

3. 캐슁(Caching)도 된다

REST 방식을 제대로 적용한다면, 즉 ReSTful하게 잘 만든다면, 웹에서 캐쉬기능도 그대로 활용할 수 있습니다. 아시다시피, 웹에서는 동일한 내용을 계속조회할때 중간노드에서 프락시를 사용하여 트래픽을 줄이기도 합니다. (IE 브라우저 옵션에 보시면 HTTP-Proxy 설정부분이 있는데 바로 그 부분을 말합니다) 그런데, 웹서비스도 알고보면 업데이트보다는 조회가 훨씬 많다는 것이고, 그 조회의 대답은 앞단에서 Proxy가 캐쉬한 값을 전달해서 처리할 수도 있다는 얘기입니다. 잘 사용하면 서버 부하, Response time을 확 줄일 수 있겠죠. 

(출처: http://knowledgehub.zeus.com/media/caching_01.png)

4. 개발자에게 상당히 직관적이다. 

이것도 앞에서 말씀드렸던 내용인데, HTTP 동사를 그대로 사용하고, 예외코드도 그대로 사용하므로, 개발자 관점에서는 상당히 익숙하고 직관적으로 이해할 수 있습니다. 즉 REST로 OpenAPI를 제공하면, 매개변수와 URI에 집중하면 되고, 함수를 실제 호출하고 사용하는 방식에 있어서, 많은 부분 RESTful하다는 얘기로 설명이 된다는 부분입니다. 

(출처: http://4.bp.blogspot.com)

5. 컨텐츠 협상(Negotiation)이 가능하다. 

아니 프로그램에서 웬 협상하실 겁니다. 그런데, Open API는 클라이언트 서버처럼 Tight couple된 관계가 아니라서, 어떤 놈이 HTTP-request를 날릴지 모르는 것이고, 그 놈이 서버에서 제공해주는 HTTP-response를 다 알아 먹을 수 있는지도 알 수 없다는 점입니다. 즉, Response가 기본 한글인데, 함수를 호출한 놈은 영문만 받아들 일 수 있다면, HTTP에서는 컨텐츠 협상을 통해, 이 요구에 대해서는 좀 다르게 응답을 할 수도 있는 것이지요. (아마 HTTP request를 할때, 본문에서 Accept-Language header를 활용하여 이런 협상을 하게되겠죠)

(출처: http://www.isoc.org/inet96)

일반적으로 서버 프로그램하면서 이런 것까지 다 고려해서, 확장성을 확보하기는 사실 어렵습니다. 기껏 한다고 해봐야, if절이나 예외처리(Try catch) 몇개로 해결할 뿐이죠. 그런데 HTTP는 언어나 미디어타입(MIME)까지 기본적으로 협상할 수 있게 왁꾸가 되어 있는 것입니다. 제게는 이런 Feature가 참 아름다운데, 그렇지 않으신지요 ^^; 

(출처: http://www.bbc.co.uk)

6. 웹 기술은 다 써먹을 수 있다. 

데이타를 주고받는데 가장 확장성있는 방법은 누구나 인정하듯 XML입니다. 그래서 웹에서 XML은 엄청 널리 쓰이고 있습니다. REST에서는 결과값을 전달하는 데 있어서 복잡한 내용도, 구조적인 결과도 XML로 처리할 수 있는 것입니다. 

(출처: http://esto.nasa.gov)

아울러 웹은 HTTP-response로 전달될 결과값이, 그리 복잡한 구조도 아니고, 아주 간편한 처리를 할 수 있도록 할 경우 JSON을 쓰기도 합니다. (JSON은 JavaScript에서 손쉽게 구조적인 값을 주고받는 방식이지요) REST에서도 이 방식도 그대로 사용할 수 있습니다. (JSON을 쓸경우, HTTP request의 헤더중에 "Accept: application/json"이 들어가게 되겠지요)

결국 REST에서는 널리 사용되는 웹기술(HTTP + URI + XHTML + XML + JSON ...)을 그대로 받아들여 OpenAPI를 아주 실용적인 관점에서 접근하게 해주는 셈입니다. 

[끝으로 한마디]

제가 설명한 것외에도 HTTP 프로토콜을 사용함으로 얻는 이점은 더 많이 있을 것입니다. HTTP를 아는 사람이라면 새로 배울 필요가 없다, 개발툴, 검증/테스트가 쉽다 등등 말입니다. 그래서 REST는 OpenAPI로 각광받는 것이며, 아울러 계속해서 발전 진화하고 있습니다. WOA(Web oriented architecture)나 WOT(Web of things)같은 게 그발전, 활용도의 극대화 예라고도 할 수 있겠습니다. 

아무쪼록 웹하시는 분들, 매쉬업 아이템을 기획하시는 분들은 REST의 기본개념은 알아두시기 바랍니다.