SOAP? REST? REST API? 무엇인가? :: 마이구미

이번 주제는 REST API에 관한 글이다. (REST와 RESTful 같다고 생각하자)

이전부터 지금까지 많이 볼 수 있는 트렌드이다.

다들 대략적인 의미는 알고 있을 것이라 생각한다.

이번 글에서는 연관된 것들과 함께 조금 더 자세히 알아보고자한다.

예를 들어,

REST API를 다룰려고 하니 ROA, SOA, SOAP, REST 등등 많은 단어들이 연관되어 있다.

궁금했지만 그냥 넘어간 경우가 있을 거라 생각해서 글을 써보려한다.

나 또한 그랬으니.. 

사실 글을 쓰는 이유는 ....

회사도 퇴사하고...ㅎ-ㅎ

JSCON을 다녀와 나의 무지를 너무나 심각하게 느낀 나머지.. 다시 공부한다는 생각으로 하다보니...

고만하고... 시작해보자.

먼저 API가 무엇인지 알아야한다.

단순히 웹 관점에서 본다면 데이터를 요청하고 응답을 위한 인터페이스라고 볼 수 있다.

일단 분류를 해보자.

SOAP 기반의 웹 서비스, RESTful 기반의 웹 서비스로 나뉠 수 있다.

찾아봤으면 알겠지만... 이 글이 처음이라면 다른 글들도 찾아보고 오면 좋다..

SOAP를 대안으로 나온 것이 RESTful 기반이다.

위키에서 보이는 정의를 보자.

SOAP

SOAP(Simple Object Access Protocol)은 일반적으로 널리 알려진 HTTP, HTTPS, SMTP 등을 통해 XML 기반의 메시지를 컴퓨터 네트워크 상에서 교환하는 프로토콜이다.

REST

REST(Representational State Transfer)는 월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식이다. REST 원리를 따르는 시스템은 종종 RESTful이란 용어로 지칭된다

일단 그렇구나 하고 보자. 계속해서 설명할 것이다.

또한 SOAP, REST에 대해 조금 더 찾아봤다면,

SOA, ROA에 대한 정보도 봤을 것이다.

SOAP 기반 서비스는 SOA 개념을 실현하기 위한 기술이다.

SOAP와 SOA는 완전히 다른 의미의 스펠링이다. (참고하라는 것이다)

RESTful 기반 서비스는 ROA 개념의 기술이라고 보면 된다.

그렇다면, SOA, ROA는 무엇인가?

이것 또한 일단 위키 정의를 보자.

SOA

서비스 지향 아키텍처(Service Oriented Architecture, 약칭 SOA 「에스오에이」혹은 「소아」로 발음)란 대규모 컴퓨터 시스템을 구축할 때의 개념으로 업무상에 일 처리에 해당하는 소프트웨어 기능을 서비스로 판단하여 그 서비스를 네트워크상에 연동하여 시스템 전체를 구축해 나가는 방법론이다. 

ROA

자원 지향 아키텍처(Resource Oriented Architecture)으로, 소프트웨어 공학에서 리소스 지향 아키텍처 (ROA)은 "RESTful" 인터페이스 자원의 형태로 소프트웨어를 설계 및 개발을 위한 소프트웨어 아키텍처와 프로그래밍 패러다임의 스타일이다. 이러한 리소스는 다른 용도로 재사용 될 수 있는 소프트웨어 구성 요소 (부호의 개별 조각 및 / 또는 데이터 구조)이다. ROA 설계 원칙과 지침은 소프트웨어 개발 및 시스템 통합의 단계에서 사용된다.

SOA에 대해서는 https://blogs.idincu.com/dev/?p=110 참고하자.

ROA은 위키 정의에도 보이듯이 REST를 위한 아키텍처라고 봐도 무방하다.

해석 그대로 서비스를 제공하는 시스템의 리소스가 중요시 되는 구조이다.

그렇다면 이제 SOAP와 REST의 흐름에 대해 알아보자.

SOAP

웹서비스 내의 모든 데이터는 XML로 표현된다.

그 데이터들과 이를 다룰 수 있는 오퍼레이션들이 WSDL로 정의되면 UDDI라는 전역적 서비스 저장 소에 등록(publish)되어 누구라도 서비스를 찾을 수 있도록 공개된다. 공개된 웹서비스가 이용될 때, 서비스 요청자와 서비스 제공자 간에 SOAP을 이용하 여 서비스를 호출하고 결과를 돌려받게 된다.  SOAP 메시지는 아래 그림과 같이 SOAP 봉투(envelope), SOAP 헤더(header), SOAP 바디(body)로 구성된 하나의 XML 문서로 표현되는 데 이러한 복잡한 구성으로 인해 HTTP 상에서 전 달되기 무겁고, 메시지 인코딩/디코딩 과정 등 웹 서비스 개발의 난이도가 높아 개발 환경의 지원이 필요하다.

WSDL 용어는 XML이라고 보면 되고, UDDI는 일종의 검색 엔진이라고 보면 된다.

WSDL, UDDI는 웹 표준이기에 너무 복잡하게 생각하지 않아도 된다.

REST

REST는 HTTP 프로토콜로 데이터를 전달하는 프레임워크이다. 또 한 클라이언트/서버 간의 구성요소를 엄격히 분리하여 구현은 단순화시키고 확장성과 성능은 높일 수 있는 아키텍처다. 여기서 리소스 (resource)란 REST 아키텍처의 핵심 요소로서 웹 사이트, 블로그, 이미지, 음악, 이용자, 지도, 검색 결 과 등 웹에서 다른 이들과 공유하고자 개방된 모든 자원을 의미한다. REST 구조에서의 리소스는 그들 의 고유한 URI를 가지며, HTTP의 기본 메소드인 GET/PUT/POST/DELETE만으로 접근할 수 있다. 

SOAP와 달리 리소스를 등록하고 저장하는 UDDI와 같은 중간 매체없이 고유 URL을 통해 직접 바로 전송하기 때문에 단순하고 빠르다.

또한 개발 환경 또한 셋팅할 필요도 없다.

왜냐면 사실 상 구현에서 따지자면 위의 정의와 그림대로 리소스들을  HTTP를 통해 요청하고 응답받는 것이 전부이다.

그렇다면 REST API는 무엇인가?

REST는 아키텍처라고 계속해서 정의하고 있다.

실질적인 구현이 아닌 설계적 지침이라고 보면 된다.

REST라는 설계를 가진 API라고 보면 된다.

이렇게 설명하는 이유는 요즘 API를 통한 처리가 많이 이루어지고 있다.

그렇기에 이러한 서비스들은 모두 REST API라고 생각하는 경우가 있다.

그렇기에 이러한 구조를 통해 만들었다하여도 쉽게 REST API이라고 말하고 다니면 안된다.

예를 들어 GET방식이 속도가 빠르고 쉽고 간단하니 그냥 어떤 기능이든 GET을 통해 처리하면 되겠네.

예약 생성 : GET /reservation/2013012500001?cmd=insert
예약 수정 : GET /reservation/2013012500001?cmd=update
예약 조회 : GET /reservation/2013012500001?cmd=select
예약 취소 : GET /reservation/2013012500001?cmd=delete

이렇게 해도 솔직히 서비스에 크게 영향은 없다.

내가 근무했던 곳도 모든 API를 GET 방식으로 요청했다.

왜냐면 퍼포먼스에 조금 더 신경을 써야하는 서비스이기 때문이다.

결론적으로 이 서비스는 REST하지 않다.

그 외에도 많은 원칙들이 있다.

REST API를 구현할 때는 기본 원칙과 지침이 따라야 한다.

원칙에 대해서는 구글 검색을 통해 많이 볼 수 있다.

아래 링크도 그 중 하나이다.

당신의 API가 RESTful 하지 않는 5가지 증거

관련된 좋은 답변이 있어 남기겠다.

RESTful API를 구현하는 근본적인 목적이 퍼포먼스 향상에 있는게 아니라, 일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높이는게 주 동기이니, 퍼포먼스가 중요한 상황에서는 굳이 RESTful API를 구현하실 필요는 없습니다.

http://okky.kr/article/347481

http://www.slideshare.net/yjaeseok/soap-rest