SOAP과 REST 비교

현재 재직중에 있는 회사에서는 SOAP을 사용하고 있기 때문에, SOAP은 겪어봤지만 REST 관련 개발을 겪어보지 못하여 정리하고자 한다.

 

용어 정리

 

• SOAP는 Simple Object Access Protocol의 약자이며 일반적으로 XML 형식을 사용하는 기 정의되어있는 형식을 사용하는 Protocol입니다.
• REST는 REpresentational State Transfer의 약자이며 표준을 정의하지 않는 아키텍처 스타일입니다. 일반적으로 JSON이 많이사용되지만, XML, YAML 등 protocol을 강제하지 않습니다.

SOAP API란 ?

 

SOAP(Simple Object Access Protocol)는 그 자체로 프로토콜이며, 보안이나 메시지 전송 등에 있어서 REST보다 더 많은 표준들이 정해져있기 때문에 조금 더 복잡합니다. 이러한 표준들로 인해서 오버헤드가 많기는 하지만, 보안, 트랜잭션, ACID(원자성, 일관성, 고립성, 지속성)을 준수해야 하는 보다 종합적인 기능이 필요한 조직에게는 적합한 방식이 될 수 있습니다. 굳이 비교를 하자면, SOAP는 웹 서비스 시나리오에 적용하기에는 그다지 좋지 않기 때문에, 기업용 애플리케이션 등을 작업하는데 더 이상적이라고 말할 수 있습니다.

SOAP는 보안 수준이 엄격합니다. SOAP에서는 SSL도 지원하고 WS-Security라는 자체 표준의 보안 기능도 가지고 있습니다.  따라서 은행용 모바일 앱처럼 보안 수준이 높아야 하거나, 신뢰할 수 있는 메시징 앱, 또는 ACID를 준수해야 하는 경우라면 SOAP 방식이 더욱 선호됩니다.

REST에서는 표준화된 메시징 시스템이 갖춰져 있지 않으며, 통신 장애가 있을 경우 재시도를 통해서만 조치할 수 있습니다. 반면 SOAP 표준에는 성공/반복 실행 로직이 규정되어 있기 때문에, SOAP API를 통해서 통신을 할 때 처음부터 끝까지 신뢰성을 제공합니다.

SOAP 표준에는 ACID 준수에 관한 사항이 있습니다. ACID를 준수하기 때문에 데이터의 변형을 줄여주고, 데이터베이스와의 상호작용에 대해서 사전에 정확하게 정하기 때문에 데이터의 무결성을 지켜주지요. ACID는 데이터 일관성을 위한 다른 방식들보다도 더 보수적이기 때문에, 금융 정보 등의 민감한 데이터를 주고받을 때 일반적으로 많이 사용됩니다.

 

-> 위 글에서 밑줄 치여진 부분이 SOAP을 이용하는 가장 큰 이유일 듯 싶다. 현재 홈택스에서도 SOAP 통신을 이용해서 세금계산서 발행을 처리하고 있는데, 금융정보 처럼 민감한 정보 처리의 경우 SOAP이 성능 및 개발 난이도상에서 REST보다 떨어지지만 사용하는 이유일 것이다.

 

REST API란 ?

 

REST API란?

REST(Representational State Transfer)는 네트워크를 통해서 컴퓨터들끼리 통신할 수 있게 해주는 아키텍처 스타일입니다.

REST API는 인터넷 식별자(URI)와 HTTP 프로토콜을 기반으로 합니다. REST는 HTTP 프로토콜 덕분에 ‘단순함’이 핵심이라고 할 수 있습니다. 데이터 포맷으로는 브라우저 간 호환성이 좋은 제이슨(JSON)을 주로 사용합니다. REST API는 구축과 확장이 간단하지만, 크고 복잡하게 만들 수도 있습니다. 이는 API를 어떻게 만들고, 무엇을 추가하고, 어떤 목적으로 설계되었는지에 따라 달려있습니다.

REST는 웹에 최적화되어 있고, 데이터 포맷이 JSON이기 때문에 브라우저들 간에 호환성이 좋습니다. 또한, 그 성능과 확장성이 뛰어난 것으로도 알려져 있습니다.

 

 

분류	설명	장점	단점
SOAP	- Simple Object Access Protocol  - 웹상에서 컴퓨터간의 웹 서비스 통신을 위한 프로토콜  - 애플리케이션계층의 프로토콜로 분류  - HTTP 프로토콜과 함께 사용  - HTTP, HTTPS, SMTP 등을 통해 XML 기반의 메시지를 컴퓨터 네트워크 상에서 교환하는 프로토콜  - SOA서비스 방식으로 데이터에 직접 접근보다는 해당 데이터에 대한 메소드를 각각 구현이 메소드를 이용하여 해당 데이터를 취득	- 표준화 되어 있는 기반  - 프록시나, 방화벽에 구애 받지 않는다  - 플랫폼과 프로그래밍에 독립적이다. 분산환경에 적합  - 웹 서비스를 제공하기 위한 표준(WSDL, UDDI)이 잘 정립되어 있다	- 너무 어렵다, 무겁다, 느리다  - 구현하기 어렵고 기계어에 가까운 문제점  - 복잡한 구조로 인한 오버헤드가 있으며 이는 SOAP의 확장을 저해하고 있다  - REST에 비해 상대적으로 무겁고 속도도 느리다  - 개발 난이도가 높아 개발 환경의 지원이 필요하다
REST	- Representational State Transfer  - HTTP를 통해 세션 트랙킹 같은 부가적인 전송 레이어 없이, 전송하기 위한 아주 간단한 인터페이스  - HTTP등의 기본 개념에 충실히 따르는 웹 서비스  - ServiceRegister를 거치지 않고 리소스 요청을 바로 받아 들인다.   - ROA 서비스 방식으로 데이터에 대한 접근방식이 간단하다.   - PUT/GET과 같은 간단한 함수로 해당 데이터를 쉽게 취득할 수 있다  - URI와 HTTP 메소드를 이용해 객체화된 서비스에 접근하는 것	- 플랫폼, 프로그래밍에 독립적이다.  - 가볍고 빠르고 쉽다  - SOAP보다 개발하기가 단순하므로 학습곡선이 작고 도구가 거의 필요없다	- HTTP 프로토콜에서만 사용가능 - point to point 통신 모델을 가정하므로 둘 이상으로 상호작용하는 분산환경에 비적합  - 보안, 정책 등에 대한 표준이 없다

출처 :  https://unknownyun.tistory.com/

SOAP vs REST