SOAP(Simple Object Access Protocol)은 다른 언어로 다른 플랫폼에서 빌드된 애플리케이션이 통신할 수 있도록 설계된 최초의 표준 프로토콜이다.
프로토콜이기 때문에 복잡성과 오버헤드를 증가시키는 빌트인 룰을 적용하므로 페이지 로드 시간이 길어질 수 있다.
빌트인 컴플라이언스 표준에는 보안과 안정적인 데이터베이스 트랜잭션의 기본 속성인 원자성, 일관성, 격리성, 내구성이 포함된다.
일반적인 웹 서비스 사양에는 다음이 포함된다.
데이터에 대한 요청이 SOAP API로 전송되는 경우 HTTP(웹 브라우저), SMTP(이메일), TCP 등 다양한 애플리케이션 레이어 프로토콜을 통해 처리될 수 있다.
요청이 수신되면, 인간과 기계가 모두 읽을 수 있는 XML 문서 형식으로 반환 SOAP 메시지가 반환된다.
SOAP API에 대해 완료된 요청은 브라우저에서 캐시할 수 없으므로 API로 재전송하지 않는 한 이후에 액세스할 수 없다.
Envelope는 모든 메시지의 코어이다. 태그로 메시지를 시작하고 끝내며 이를 감싸안아 이름을 지정한다.
Header(optional)은 메시지의 세부사항과 추가 요구사항을 결정한다.
Body에는 request나 response이 포함된다.
Fault(optional)은 API 요청 및 응답 전반에 걸쳐 나타날 수 있는 오류에 대한 모든 데이터를 표시한다.
대부분의 레거시 시스템에서는 SOAP을 준수한다고 한다.
REST는 그보다 나중에 고려하거나 웹 기반 시나리오에서의 더 빠른 대안으로 여기는 경우가 많다.
REST는 유연한 구현을 제공하는 가이드라인 세트고, SOAP는 XML 메시징과 같은 특정 요건이 있는 프로토콜이다.
REST API는 경량화되어 있기 때문에 사물 인터넷(IoT), 모바일 애플리케이션 개발, 서버리스 컴퓨팅과 같이 보다 새로운 컨텍스트에 이상적이다.
SOAP 웹 서비스는 많은 기업에서 필요로 하는 기본 보안과 트랜잭션 컴플라이언스를 제공하지만, 이것 때문에 좀 더 무거운 경향이 있다.
Google Maps API와 같은 대부분의 퍼블릭 API는 REST 가이드라인을 따른다.
고도로 표준화된 작업
모든 종류의 잘못된 해석을 제거해야 하는 모든 사용 사례는 SOAP 통신에 적합하다.
일반적으로 이런 시스템에는 WSDL 문서로 설명할 수 있는 명확하게 정의된 논리가 포함된 엄격한 계약이 있다.
은행 거래 및 지불 시스템
트랜잭션이 항상 신뢰할 수 있고 제 3자가 연결할 수 없도록 해야하는 경우 SOAP에는 고려해야할 여러 이점이 있다.
- ACID 준수 및 WS-Security 프로토콜을 통한 보안 수준이다.
또한 이런한 사용 사례 집합에는 일반적으로 상태 저장 메시징이 필요하다.
- 서로 격리되지 않은 체인 트랜잭션을 사용한다.
- 지불 시스템에는 단일작업에 여러 당사자가 포함될 수 있으므로 SOAP을 사용해 행동을 조정할 수 있다.
항공편 예약 시스템
항공편 예약은 일반적으로 여러 당사자를 포함하기 때문에 이 업계의 일부 공급자는 상태 저장 및 연결 메시징을 처리하기 위해 여전히 SOAP을 사용한다고 한다.
비 HTTP 메시징 및 레거시 환경
서버 요구사항 및 기존 시스템이 HTTP 이외의 통신 프로토콜을 활용하는 경우 SOAP가 가장 먼저 살펴볼 옵션이다.
https://www.redhat.com/ko/topics/integration/whats-the-difference-between-soap-rest
https://www.altexsoft.com/blog/engineering/what-is-soap-formats-protocols-message-structure-and-how-soap-is-different-from-rest/