SOAP
SOAP(Simple Object Access Protocol)은 일반적으로 널리 알려진 HTTP, HTTPS, SMTP 등을 통해 XML 기반의 메시지를 컴퓨터 네트워크 상에서 교환하는 프로토콜이다. SOAP은 웹 서비스에서 기본적인 메시지를 전달하는 기반이 된다. SOAP에는 몇가지 형태의 메시지 패턴이 있지만, 보통의 경우 원격 프로시져 호출(Remote Procedure Call:RPC) 패턴으로, 네트워크 노드(클라이언트)에서 다른 쪽 노드(서버)로 메시지를 요청 하고, 서버는 메시지를 즉시 응답하게 된다. SOAP는 XML-RPC와 WDDX에서 envelope/header/body로 이루어진 구조와 전송(transport)과 상호 중립성(interaction neutrality)의 개념을 가져왔다.
SOAP은 XML을 근간으로 헤더와 바디를 조합하는 디자인 패턴으로 설계되어 있다. 「헤더」는 선택사항으로 반복이나 보안 및 트랜잭션을 정보로 하는 메타 정보를 가지고 있다. 「바디」부분은 주요한 정보인 정보를 가지고 있다.
장점
- SOAP을 사용한 HTTP는 기존 원격 기술들에 비해서 프록시와 방화벽에 구애받지 않고 쉽게 통신 가능하다.
- SOAP은 융통성있게도 각각 다른 트랜스포트 프로토콜들의 사용을 허용하고 있다. 표준 스택에서는 트랜스 포트 프로토콜로 HTTP를 사용하지만, 다른 프로토콜 역시 사용가능 하다.
- SOAP은 플랫폼 독립적이다.
- SOAP은 프로그래밍 언어에 독립적이다.
- SOAP은 확장가능하다.
분산환경 하에서 정보교환을 하기 위한 하나의 프로토콜인 SOAP은 다음과 같은 장점을 가지고 있다(안현수, 2003).
- SOAP은 전송(Transport) 매체로서 HTTP를 사용하기 때문에 인터넷에서 널리 사용할 수 있다. 실제로 SOAP은 인터넷에서 원격 객체를 액세스하기 위해 고안된 프로토콜이다.
- SOAP은 HTTP와 XML을 사용하기 때문에 개발도구나 플랫폼에 구애받지 않고 SOAP 서버 혹은 클라이언트를 개발할 수 있다. 이처럼 SOAP 서버 혹은 클라이언트를 보다 쉽게 개발할 수 있도록 해주는 COM 컴포넌트, 유틸리티 등으로 구성된 SOAP 툴킷(toolkit)도 제공되고 있다. 또한 HTTP와 XML이 갖는 장점을 모두 포함하면서 컴포넌트의 상호운용성을 높일 수도 있다.
- SOAP은 컴포넌트를 활성화하는 방법이나 호출하는 방법에 대해 전혀 관여하지 않으며 이에 대한 상세한 사항은 HTTP Request를 수신하는 수신자에게 위임하고 있다. 따라서 객체지향기술이나 컴포넌트 기술을 사용하지 않는 애플리케이션일지라도 SOAP을 통해 객체서비스를 제공하거나 제공받을 수가 있다.
단점
- XML 포맷은 태그 형태로 보내기 때문에 CORBA같은 미들웨어 기술과 비교해서 상대적으로 느리다. 이것은 전송할 메시지가 적을때에는 문제 되지 않을 수 있다. 성능을 향상시키기 위해서 바이너리 객체를 포함시킨 특별한 경우의 XML(바이너리 XML을 말하는듯)로 메시지 전송 최적화 메커니즘(Message Transmission Optimization Mechanism; MTOM)이 나왔다. 게다가 일반적인 XML의 성능을 향상시키기 위해, VTD-XML과 같은 emerging non-extractiv XML 처리 모델이 있다.
REST vs SOAP
Redhat 문서
Rest vs soap 비교
https://www.redhat.com/en/topics/integration/whats-the-difference-between-soap-rest
REST API란?
REST(Representational State Transfer)는 네트워크를 통해서 컴퓨터들끼리 통신할 수 있게 해주는 아키텍처 스타일입니다. REST API는 인터넷 식별자(URI)와 HTTP 프로토콜을 기반으로 합니다. REST는 HTTP 프로토콜 덕분에 ‘단순함’이 핵심이라고 할 수 있습니다. 데이터 포맷으로는 브라우저 간 호환성이 좋은 제이슨(JSON)을 사용합니다.
REST API는 구축과 확장이 간단하지만, 크고 복잡하게 만들 수도 있습니다. 이는 API를 어떻게 만들고, 무엇을 추가하고, 어떤 목적으로 설계되었는지에 따라 달려있습니다. REST API는 클라이언트와 서버 사이에서 통신할 수 있게 하고, 아키텍처를 만들 수 있게 해줍니다. REST 방식의 API라면, 클라이언트-서버 모델로 구축되었다는 것을 의미하며, 정보의 페이로드(실제 전달하려는 내용)가 두 지점 사이를 왕복하게 됩니다.
REST API는 단일한 인터페이스를 사용합니다. 이러한 점 때문에해당 API를 사용하는 애플리케이션들이 동일한 경로를 통해서 접속해야 하고, 그 방식이 단순하게 됩니다. 여기에는 장점도 있고, 단점도 있기 때문에 향후 개발 과정에서 어떤 영향이 있는지에 대해서 알고 싶다면 전문가와 상의해보는 것이 좋습니다.
REST는 웹에 최적화되어 있고, 데이터 포맷이 JSON이기 때문에 브라우저들 간에 호환성이 좋습니다. 또한, 그 성능과 확장성이 뛰어난 것으로도 알려져 있죠. 하지만 다른 기술들과 마찬가지로 그 자체의 기능이 정지되거나 여러분의 앱을 먹통으로 만들 수도 있습니다. 그래서 REST로는 풀지 못하는 문제들을 해결하기 위해서 그래프 QL과 같은 언어가 생겨난 것입니다.
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 REST 차이’ : 핵심적인 차이들
SOAP는 프로토콜이고, REST는 아키텍처 스타일입니다. API는 애플리케이션이 서버에 접속할 수 있도록 설계된 일종의 도구이며, SOAP는 서비스 인터페이스를 이용해서 서버에 접근하고, REST는 URI를 이용해서 접근합니다.
API라는 것은 결국은 앱의 페이로드를 처리하기 위해서 만들어진 것인데, ‘SOAP REST 차이’는 페이로드를 처리하는 방식에 있습니다. 페이로드는 인터넷을 통해서 전송되는 데이터입니다. 그렇기 때문에 페이로드가 ‘무거운’경우에는 더 많은 리소스가 필요합니다. REST는 HTTP와 JSON을 사용하기 때문에 페이로드의 무게를 가볍게 할 수 있습니다. 하지만 SOAP에서는 XML에만 의존합니다.
‘SOAP REST 차이’는 보안을 다루는 방식에서도 볼 수 있습니다. SOAP는 WS-Security를 지원하는데, WS-Security는 전송 레벨에서 아주 뛰어나며 SSL보다도 조금 더 복잡하기 때문에 기업용 보안 도구에 통합하는데 보다 이상적입니다. 둘 다 양단간(end-to-end) 보안성을 위해서 SSL을 지원하며, REST에서는 HTTP의 보안 버전인 HTTPS 프로토콜을 이용할 수 있습니다.
SOAP는 서버와 긴밀하게 연결하며, REST는 보다 느슨한 형태로 연결됩니다. 프로그래밍을 할 때는 일반적으로 추상화 계층이 더 많을수록 양쪽의 상호작용에서 통제할 수 있는 부분이 줄어들기는 하지만 오히려 구현하기는 쉬우며, 나중에 그 방식을 전부 고치지 않고도 업데이트를 쉽게 할 수 있는 편입니다. API를 이용해서 서버와 상호작용할 때에도 마찬가지입니다. 그리고 바로 이 부분에서 ‘SOAP REST 차이’를 보이고 있습니다. SOAP는 서버와 매우 긴밀하게 연결되기 때문에 그 통신 방식이 매우 엄격하며, 그래서 수정이나 업데이트를 하는 것이 보다 더 어렵습니다. REST 방식의 API에서는 클라이언트에서 해당 API가 필요하지 않지만, SOAP 방식의 API에서는 상호작용을 시작할 때조차도 클라이언트에서 API에 관한 모든 정보들을 필요로 합니다.
SOAP REST 차이, 어떤게 더 좋을까?
웹서비스에서는 SOAP가 확실하게 좋은 방법이 아니라면 개발자들이 REST 방식의 API를 택하는 경우가 많으며, 기업용 애플리케이션인 경우에는 보다 많은 리소스와 아주 엄격한 보안 그리고 여러 다양한 요구 사항들을 만족해야 하기 때문에 SOAP 방식을 택하는 경우가 많습니다.
