REST API 아키텍처 : 개념, 방법, 개요, 설명

Representational State Transfer (REST)

Language API를 사용하는 것뿐만 아니라 최근에는 REST라고 하는 방법을 사용하여 OpenAPI 서비스들을 제공하는 웹사이트들이 늘어나고 있습니다. REST는 Representational State Transfer의 약자로서 웹의 분산된 Hypermedia 콘텐츠를 접근하기 위해 개발된 Software Architecture Style입니다.

이 REST 아키텍처에서는 웹의 각 Hypermedia 자원이 고유한 주소를 가지고 있습니다. 이 자원에 대한 수정이 HTTP 인터페이스를 통해 Domain Specific한 데이터를 전송함으로써 이루어지게 됩니다. 즉, SOAP을 활용해서 메시지를 전달할 필요가 없이 애플리케이션에서 웹의 자원과 서비스를 HTTP의 Get, Post, Put, Delete Method들만을 사용해서 직접적으로 접근하고 제어할 수 있는 방법이 바로 REST입니다.

그리고 이때 데이터 전송을 보통 XML이나 JSON을 형태를 사용해서 수행합니다. 이러한 REST를 사용하는 소프트웨어 아키텍처를 우리는 보통 RESTful 아키텍처라고 부릅니다.

 

 

Example: Google Search

Google의 검색 서비스를 활용할 때 구글 홈페이지에 접속해서 검색 Query를 입력합니다. 그렇게 하는 대신에 URL을 만들어서 웹브라우저 주소창에 직접 입력하여도 우리는 같은 검색 결과를 얻을 수 있습니다. Google의 Search Operation이 명시되어 있습니다. 이후 이 Operation 호출에 필요한 Parameter 값으로서 검색 Query인 “Cloud Computing”이 명시되어 있는 것을 확인할 수 있습니다. 이것은 Google의 검색 서비스가 RESTful 인터페이스를 통해서 접근 가능함을 의미합니다.

 

 

REST Principles

그럼 RESTful 아키텍처가 따라야 할 REST Principle이 있습니다. 먼저 RESTful 아키텍처를 구성하는 모든 서비스의 상태와 기능들은 자원, 즉 Resource라고 정의합니다. 그리고 각 자원은 URI 형식으로 표현되는 고유한 주소를 갖고 있습니다.

이러한 자원들에 대한 접근은 HTTP와 같은 단일 인터페이스를 통해 이루어집니다. 하나의 RESTful 인터페이스는 Operation의 집합 그리고 각 Operation을 사용할 때 교환되는 콘텐트 타입의 집합으로 구성됩니다. REST는 또한 다음과 같은 특징을 갖는 프로토콜이라고 정의합니다.

먼저 일반적인 웹서비스와 같이 Client Server 모델을 따릅니다. Stateless 프로토콜을 지원하기 때문에 언제나 클라이어트와 서버가 연결되어 상호작용하는 것이 아닙니다. 필요에 따라서 메시지를 주고받으면서 상호작용하는 모델이 됩니다.

기존 SOA와 구별되는 특징 중의 하나는 REST 프로토콜은 Cacheable하다는 것입니다. 즉 서비스의 상태를 Cache에 임시로 저장을 해서 효율적으로 서비스를 사용하고 재사용합니다. 다시 정리하면 REST 서비스와 클라이언트는 HTTP 인터페이스를 통해 서로 상호작용합니다. 이때 서비스의 상태, 즉 서비스 요청 결과는 Caching이 됩니다. 그리고 REST 서비스는 이전에 설명 드렸던 것과 같이 클라우드 상의 여러 서버에서 분산해서 실행이 됩니다.

 

REST API 아키텍처 : 개념, 방법, 개요, 설명

 

또한 그림의 오른쪽 하단에 보시는 것처럼 어떠한 REST 서비스는 또한 다른 REST 서비스를 호출해서 활용해 제공됩니다.

 

 

Example : Google Maps Geocoding

RESTful 인터페이스를 사용하는 간단한 예로서 Google Maps의 Geocoding 서비스를 활용하는 것을 알아봅니다. 이 서비스를 활용하면, 보통 거리 주소 정보가 있습니다. 그것을 위도/경도 값으로 변환할 수 있습니다.

먼저 Google Maps의 Geocoding 서비스 주소를 Google Maps OpenAPI 포털을 통해 파악해서 넣습니다. 그 이후에 Output Format으로 “Xml”을 명시합니다. 이것은 Geocoding 결과를 XML 형태로 받습니다. 그리고 그 이후에 이 서비스 Operation 실행에 필요한 Parameter 값들을 명시합니다.

이 예에서는 “Address”라는 Parameter 값으로 거리 주소, 즉 Street Address를 입력하고, “key”라는 Parameter 값으로는 Google Maps에서 얻은 접근 API 키 값을 명시하면 됩니다. Google Maps 포털의 Geocoding API 명세 페이지를 보시면 Parameter들에 대한 상세한 설명을 보실 수 있습니다.

그리고 그 이후에 이 주소를 웹브라우저 주소 창에 넣으면 다음과 같이 XML 형태로 된 Geocoding 결과를 받을 수가 있습니다. 원래 입력을 했던 거리 주소 정보가 Echoing돼서 포함이 되어 있습니다. 이어서는 이 주소에 해당하는 위도/경도 값이 Return돼서 포함돼 있는 것을 확인할 수 있습니다.

 

 

Example : Gmail Users.messages API Methods

다른 예로서 Goggle의 Gmail OpenAPI 중에서 이메일 메시지 Resource인 Users.messages를 위한 API의 상세 명세가 있습니다. 여기에는 이메일을 보내고 받고 삭제하는 작업을 위해 어떠한 HTTP Method를 어떻게 사용하면 되는지 설명되어 있습니다.

예를 들어 이메일의 목록을 보기 위해서는 HTTP GET Method를 사용해서 userId가 포함된 Parameter를 보내면 되는 것을 알 수 있습니다. 그리고 이메일 메시지 Resource 자체는 여기 보시는 JSON 스키마에 정의된 것과 같은 형식으로 그 정보와 내용이 표현됩니다. 즉, 이메일 ID, Header, Body 등의 데이터가 어떻게 표현되는지 이해할 수 있습니다.

이를 바탕으로 이메일 메시지 Resource를 JSON 데이터로 Gmail 서비스로부터 받아서 처리하거나 아니면 이메일을 새로 만들어서 발송할 수가 있습니다.

 

 

Benefits of Using REST

REST를 사용하는 것의 장점에 대해 알아보겠습니다. 먼저 서비스 요청 결과에 대한 Caching이 가능합니다. 이것 때문에 서비스에 대한 응답시간을 줄이고 서버 부하의 균형을 맞추기가 굉장히 쉬워집니다.

두 번째로 REST는 Stateless 프로토콜을 사용합니다. 이러한 프로토콜을 사용하기 때문에 클라이언트와 서버 간에 계속적인 연결유지가 필요 없습니다. 따라서 서버의 확장성이 높아지게 됩니다.

세 번째로 웹브라우저만 사용하거나 아니면 아주 간단한 클라이언트 소프트웨어를 구현하기만 하면 되기 때문에 RESTful 서비스를 사용할 때 Light-Weight한 클라언트 실현할 수 있습니다.

또한 네 번째로는 HTTP 프로토콜만을 사용하기 때문에 메시지 교환이 굉장히 쉬워집니다. 또한 SOAP과 같은 별도의 메시징을 위한 기반 소프트웨어가 필요 없습니다.

다섯 번째로 URI와 같은 Hyperlink만 사용하면 되기 때문에 별도의 서비스 레지스트리와 검색 방법의 사용이 필요 없습니다. 그렇지만 RESTful 아키텍처의 특징들은 또한 단점을 유발합니다.

즉, Stateless 프로토콜을 사용하기 때문에 어떤 Context를 유지하면서 장시간 실행돼야 하는 비즈니스 프로세스 구현하는 데는 이러한 RESTful 아키텍처가 적합하지 않습니다. 또한 HTTP만 사용하기 때문에 복잡한 서비스 간의 상호작용을 이것으로 모두 구현하기 어렵습니다. 

또한 HTTP를 통해서 대용량의 메시지를 교환하는 것도 힘든 일이 되겠습니다. 또한 표준화된 서비스 명세 모델과 레지스트리 구축을 하고 검색하는 방법이 없기 때문에 서비스 제공자마다 서로 다른 명세를 제공하게 됩니다. 이러한 명세를 사용해서 원하는 서비스를 체계적으로 검색하고 또한 Publish하는 작업들이 어렵게 됩니다. 특히 자동화된 검색 그리고 서비스 접근을 이루기가 매우 어렵습니다.

 

REST API 아키텍처 : 개념, 방법, 개요, 설명

 

즉, RESTful 아키텍처는 Light-Weight한 서비스 아키텍처이기 때문에 대규모의 엔터프라이즈 시스템에는 아직 적용하기 어려운 점이 많이 있습니다. REST를 사용하는 경우와 SOAP RPC를 사용할 때 클라이언트와 서버 간에 교환되는 메시지의 차이를 살펴보았습니다.

SOAP RPC를 사용하면 여기 보시는 것처럼 SOAP XML로 Encoding된 요청 메시지를 서버에 보내야 됩니다. 그에 대한 응답도 역시 SOAP 메시지로 표현되어 보내집니다. 반면 우리가 REST를 사용하면 보시는 것처럼 간단한 HTTP Method 호출만 통해서 서비스에 대한 요청을 보낼 수 있습니다.

그에 대한 응답으로는 XML이나 JSON 등 포맷으로 표현된 메시지를 받게 되겠습니다. 즉, SOAP RPC를 사용할 때보다 훨씬 굉장히 간단한, Light-Weight한 메시지 통신을 이룰 수 있기 때문에 그에 따라서 통신과 메시지 처리의 Overhead를 줄일 수 있습니다.

 

 

SOA와 REST의 관계

우선 SOA는 하나의 아키텍처 모델 또는 스타일입니다. 그리고 REST는 이런 것들을 구현하기 위한 구현 기술이 됩니다. 즉, REST 기술을 활용해서 SOA 구축이 가능하다는 것이 되겠습니다. 그리고 SOA의 구축 목표는 비즈니스 골을 달성합니다.

REST를 사용하는 목표는 기술적인 관점에서 비즈니스 골을 더 효과적으로 달성하도록 하기 위한 것입니다. 전통적으로 SOA 구축에 사용해 왔던 SOAP RPC를 사용하느냐 아니면 REST를 사용하느냐 하는 것들은 비즈니스 도메인의 요구사항과 관련해서 결정합니다.

또한 최근의 SOAP과 WSDL 버전들은 RESTful 웹서비스도 지원 가능하기 때문에 그러한 SOAP RPC와 REST를 같이 병행해서 사용하는 것도 가능합니다.