SOAP

"형식이 엄격한 XML 기반의 웹 서비스를 위한 메시징 프로토콜"

• 다른 언어로 다른 플랫폼에서 빌드된 애플리케이션이 통신할 수 있도록 설계된 최초의 표준 프로토콜
• 전송 프로토콜에 의존적이지 않아 HTTP뿐만 아니라 SMTP, FTP 등 다양한 프로토콜을 통해 통신할 수 있다.
• SOAP는 XML 기반의 정형화된 메시지를 주고받으며, 이로 인해 정확하고 표준화된 통신이 가능하다.
• "무엇을" "어떻게 호출할 수 있는지"를 기술한 XML 명세서인 WSDL을 통해 SOAP를 사용할 수 있다.

• 해당 명세서인 WSDL을 보고, Client는 서비스 위치(URL), 필요한 파라미터, 사용할 수 있는 메서드 등의 정보를 얻을 수 있다.
• 장점
  • WS-Security라는 표준을 통해 메시지 암호화, 디지털 서명, 인증서 기반 인증을 지원해 보안에 강하다.
    (REST는 보통 HTTPS에 의존함, 별도의 구현이 필요)
  • WSDL로 서비스의 모든 구조를 명세화하여 문서화하기 때문에, 기업 간 통신(B2B)에서 정확하고 안정적인 계약 기반 API 설계가 가능
  • 트랜잭션 처리, 메시지 신뢰성 보장으로 은행 시스템 처럼 트랜잭션이 중요한 환경에 적합
  • REST는 HTTP 기반이지만, SOAP는 SMTP, JMS 등 다양한 프로토콜 위에서도 동작 가능하여, 이메일 기반 시스템이나 메시지 브로커 기반 시스템과 통합이 가능하다.
• 단점
  • WSDL이 XML로 구성되어, 메시지가 매우 복잡하고 길다.
  • XML 파싱 비용, WSDL 처리 등으로 통신량이 많고 성능 저하가 우려됨
  • 단순한 CRUD 조차도 WSDL과 복잡한 SOAP 메시지를 구성해야 한다.
  • 모든 HTTP의 요청을 POST로 전송한다
  • 학습 곡선이 매우 높다.

=> SOAP가 기업 환경에 적합한 강력한 기능을 갖추었지만, 웹과 모바일 중심의 가볍고 빠른 서비스 요구에는 과도하게 무겁고 복잡했다.
이러한 배경 속에서 등장한 것이 바로 REST (Representational State Transfer)다.

참고- https://velog.io/@imkkuk/Protocol-SOAP

REST

"REST는 자원을 URI로 표현하고, 그 자원을 HTTP 메서드로 조작하는 방식의 아키텍처 스타일"

• GET, POST, PUT, DELETE 등 HTTP의 기본 철학을 따른다.
• WSDL 같은 명세가 없어도 URL과 메서드만 알면 간편하게 사용 가능함

REST의 장점

1. HTTP기반의 직관적인 API 설계

• 고정된 URL에도 다양한 HTTP 메서드로 의미를 부여하여 조작함
• 직관적이고 표준적이기 때문에 문서 없이도 이해하기가 쉽다
  • ex) GET /users - 사용자 목록 조회인걸 바로 알 수 있음

2. 경량 포맷(JSON 등) 사용 가능

• REST는 XML에 묶여있지 않고, 메시지 포맷에 제한이 없어 주로 JSON을 사용한다.
• JSON은 가볍고, 프론트엔드와의 호환성이 뛰어남
• 모바일 환경에서도 빠르게 요청과 응답을 전송 가능

3. WSDL 없이도 쉽게 접근 가능

• REST는 명세 파일(WSDL)이 없어도 API를 사용할 수 있음
• URL과 메서드만 알면 클라이언트는 API를 바로 요청할 수 있다.
• Swagger, Postman 같은 도구로 쉽게 테스트 가능

4. 학습 곡선이 낮고 구현이 단순함

• HTTP를 알고 있다면, REST API를 이해하기가 쉽다.
• 별도의 복잡한 설정이나 XML 파싱 없이 개발 가능
• 클라이언트-서버가 느슨하게 결합됨 (유지보수 용이)
  • 프론트엔드와 백엔드가 서로의 내부 구조나 구현 방식에 대해 몰라도 되고, 약속한 API만 지키면 된다.

5. 웹 친화적인 구조 (캐싱, 상태 코드 활용)

• HTTP의 표준 상태 코드를 활용 가능 (404, 200 등)
• GET 요청은 캐싱이 가능하여 성능이 향상됨

REST의 단점

1. 복잡한 관계 표현이 어렵다

• 리소스 간의 복잡한 연관 관계 (예: 사용자 + 주문 + 결제) 를 표현하고 전송하는 데 한계가 있음
• 이럴 때는 여러 API 호출이 필요하게 되어 Under-fetching 혹은 Over-fetching 발생

2. 표준 명세 부족

• SOAP처럼 강력한 명세(WSDL)가 없기 때문에, 팀마다 설계 방식이 달라 일관성 유지가 어려움

3. 보안이나 트랜잭션 처리에 상대적으로 약함

• 인증, 권한 처리, 메시지 무결성 등은 직접 구현해야 함 (JWT, OAuth 등으로 해결)
• 멀티 리소스에 걸친 복잡한 트랜잭션 처리는 어렵다

4. 비정형 요청에 불리

• 클라이언트가 원하는 형태의 응답을 세밀하게 조절하기 어려움
  => 그래서 등장한 것이 GraphQL (클라이언트가 요청 구조를 정의)