네 번째 작심일일, API 아키텍처 스타일 비교 - (3) SOAP

halonso14·2022년 1월 5일
2

Simple Object Access Protocol (SOAP): 데이터를 서비스로 제공

SOAP는 XML 형식의 고도로 표준화된 웹 통신 프로토콜이다. XML-RPC 출시 1년 후에 SOAP가 출시되었기 때문에 SOAP는 XML-RPC로부터 상당 부분을 물려받았다. 이후 REST가 출시되었을 때, SOAP와 REST는 같이 사용되었지만, 곧 REST만 사용하는 추세가 시작되었다.

SOAP의 동작 방식

XML 데이터 형식을 많은 형식적인 요소를 포함하고 있다. 이는 거대한 메시지 구조와 결합하여 SOAP를 가장 번거로운 API 스타일로 만든다.

SOAP 메시지는 다음과 같이 구성된다.

  • 메시지의 시작과 끝을 표시하는 envelop tag를 포함한다.
  • 요청 또는 응답을 body에 포함한다.
  • 메시지가 특정 사항이나 추가 요구 사항을 결정해야되는 경우 헤더를 포함한다.
  • 요청을 처리하는 도중 발생할 수 있는 오류에 대한 안내를 포함한다.

SOAP API 로직은 웹 서비스 기술 언어(WSDL)로 작성된다. 이 API 기술 언어는 endpoint를 정의하고 실행 가능한 모든 프로세스를 설명한다. 이를 통해 다양한 프로그래밍 언어와 IDE에서 통신 방법을 빠르게 설정할 수 있다.

SOAP는 stateful, stateless 메시지 모두 지원한다. Stateful 메시지를 사용하는 경우, 매우 과중할 수 있는 응답 정보를 서버에서 저장하게 된다. 그러나 이는 다양하고 복잡한 트랜젝션을 처리하기에 적합하다.

SOAP의 장점

언어 또는 플랫폼의 제약을 받지 않는다. SOAP는 웹 기반 서비스를 생성하는 내장 기능을 통해 통신을 처리하고 응답 언어 및 플랫폼으로부터 자유롭다.

다양한 통신 프로토콜을 사용할 수 있다. SOAP는 다양한 시나리오에 사용될 수 있도록 전통신 프로토콜 측면에서 유연하다.

에러 처리 기능을 내장한다. SOAP API 사양은 에러 코드와 설명을 담은 XML 재시도 메시지를 반환하도록 명시한다.

보안 측면에서 확장 가능하다. WS-Security 프로토콜과 통합된 SOAP는 엔터프라이즈급 트랜잭션 품질을 충족한다. SOAP는 메시지 수준에서 암호화를 허용하면서 트랜잭션 내부의 개인 정보 보호 및 무결성을 제공한다.

SOAP의 단점

최근 다수의 개발자들은 몇 몇 이유를 근거로 SOAP API를 통합해야 한다고 강력하게 주장한다.

SOAP는 XML만 사용한다. SOAP 메시지에는 많은 메타 데이터가 포함되며 요청 및 응답을 위해 장황한 XML 구조만 지원한다.

SOAP는 무겁다. 큰 XML 파일 사이즈로 인해, SOAP 서비스는 큰 대역폭을 요구한다.

SOAP는 협소하게 전문화된 지식을 사용한다. SOAP API 서버를 설계는 모든 프로토콜과 매우 제한적인 규칙에 대한 깊은 이해도를 요구한다.

SOAP 메시지 업데이트는 지루하다. SOAP 메시지를 추가 또는 삭제하기 위해서 추가적인 노력이 필요하며, 경직된 SOAP 스키마는 변경 속도를 늦춘다.

SOAP 사용 예시

SOAP 아키텍처는 일반적으로 기업 내 또는 믿을 수 있는 협력사와 내부 통합이 필요한 경우 사용된다.

SOAP는 고수준의 보안 데이터 전송에 사용된다. SOAP의 엄격한 구조, 보안 및 권한 부여 기능은 API 공급자와 API 소비자 간의 법적 계약을 준수하면서 API와 클라이언트 간의 공식 소프트웨어 계약을 시행하는 데 가장 적합한 옵션이다. 이것이 금융 기관 및 기타 기업 고객이 SOAP를 사용하는 이유이다.

참조: https://www.altexsoft.com/blog/soap-vs-rest-vs-graphql-vs-rpc/

profile
삼백 육십 오 번의 작심일일

0개의 댓글