[NETWORK] SOAP vs REST 통신 방식 정리

CDR 문서 보다가 뭔가 정리하면 좋을 거 같다고 생각해서 가져온 SOAP과 REST 비교 :D

 

SOAP (Simple Object Access Protocol)

SOAP 이란?

네트워크 상에서 정보를 교환하기 위한 프로토콜(통신 규약)'

 

핵심 특징 및 동작 원리

▶︎ XML만 허용: SOAP은 메시지의 포맷으로 XML(eXtensible Markup Language)만을 사용

▶︎ 정해진 구조: 모든 SOAP 메시지는 정해진 구조를 가져야 한다.

▶︎ Envelope: XML 문서가 SOAP 메시지임을 정의하는 최상위 요소

• Header: (선택) 보안, 인증 등 메시지 처리에 필요한 부가 정보
• Body: (필수) 실제 전달하고자 하는 핵심 데이터 (Call과 Response)
• Fault: (선택) 처리 중 발생한 에러와 상태 정보

▶︎ WSDL과 UDDI: SOAP을 제대로 사용하려면 서비스의 인터페이스(사용법)를 설명하는 WSDL(Web Services Description Language) 문서가 필수

• WSDL: 서비스 인터페이스 정의 문서 (필수)
• UDDI: 서비스 레지스트리 (현재는 거의 사용되지 않음)

 

SOAP 통신 메시지 예시

요청

POST /PaymentService/authorize HTTP/1.1
Host: api.legacy-bank.com
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://example.com/payment/AuthorizePayment"

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:pay="http://example.com/payment">
  <soap:Header>
    <pay:AuthHeader>
      <pay:ApiKey>A1B2C3D4E5</pay:ApiKey>
    </pay:AuthHeader>
  </soap:Header>
  <soap:Body>
    <pay:AuthorizePaymentRequest>
      <pay:UserId>user_88990</pay:UserId>
      <pay:Amount>5000</pay:Amount>
      <pay:Currency>KRW</pay:Currency>
      <pay:Description>프리미엄 구독권 결제</pay:Description>
    </pay:AuthorizePaymentRequest>
  </soap:Body>
</soap:Envelope>

 

장점

▶︎ 강력한 자체 보안 표준(WS-Security)을 지원

▶︎ WS-Transaction 등의 확장 스펙을 통해 트랜잭션 처리를 지원 (ACID 보장 가능)

▶︎ 재시도 로직 등이 프로토콜 내에 내장되어 있어 신뢰성 높음

 

단점

▶︎ 태그가 많아 데이터 크기(Payload)가 큼

▶︎ 파싱(Parsing) 속도가 느림

▶︎ 개발 환경을 세팅(예: Java의 JAX-WS 설정 등)하는 과정이 다소 복잡하고 무거움

---

REST (Representational State Transfer)

REST란?

어려운 프로토콜(규약)이 아닌, 웹(HTTP)의 기존 인프라를 최대한 활용하기 위한 소프트웨어 아키텍처 스타일 설계 가이드라인

 

핵심 특징 및 제약 조건

REST는 프로토콜이 아닌 가이드라인이고, 아래의 원칙들을 잘 지켜 설계된 API가 RESTful API

 

▶︎ 자원(Resource)의 명시: URL은 행위가 아닌 자원로만 구성되어야 합니다. (예: /getUsers ❌ ➔ /users ⭕)

▶︎ 행위(Verb)는 HTTP 메서드로: 자원에 대한 CRUD(생성/조회/수정/삭제)는 HTTP 메서드로 표현합니다.

• POST (Create - 생성)
• GET (Read - 조회)
• PUT / PATCH (Update - 수정)
• DELETE (Delete - 삭제)

▶︎ 무상태성 (Stateless): 서버는 클라이언트의 상태(세션 등)를 기억하지 않습니다. 각 요청은 완벽히 독립적이어야 하며, 필요한 정보는 클라이언트가 요청 시 모두 담아 보내야 합니다.

▶︎ 캐시 처리 가능 (Cacheable): HTTP 표준을 그대로 사용하므로, 웹 서버의 강력한 캐싱 기능을 활용해 대량의 요청을 효율적으로 처리할 수 있습니다.

 

REST 통신 메시지 예시

[Client 요청]

GET /users/12345 HTTP/1.1

 

[Server 응답 (JSON)]

POST /api/v1/payments/authorize HTTP/1.1
Host: api.modern-service.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIs... (JWT 토큰)

{
  "userId": "user_88990",
  "amount": 5000,
  "currency": "KRW",
  "description": "프리미엄 구독권 결제"
}

 

장점

▶︎ 데이터 포맷이 자유롭고(주로 JSON 사용) 읽기 쉬움

▶︎ 통신 페이로드가 가벼워 속도가 빠름

▶︎ 서버와 클라이언트의 역할을 완벽히 분리해 확장에 매우 유리

단점

▶︎ 명확한 '표준'이 없기 때문에 개발자마다 설계 방식이 달라질 수 있음

▶︎ 표준이 엄격하지 않아 설계 일관성을 유지하기 어려울 수 있음
▶︎ 보안, 인증, 트랜잭션 등을 별도로 설계해야 함

 

SOAP vs REST, 한눈에 비교하는 요약표 📊

비교 항목	SOAP (Simple Object Access Protocol)	REST (Representational State Transfer)
개념	엄격하게 정의된 통신 프로토콜	웹의 장점을 활용하는 아키텍처 스타일
데이터 형식	XML 전용	JSON(주로 사용), XML, Plain Text 등 유연함
전송 방식	HTTP, SMTP, TCP/UDP 등 다양함	대부분 HTTP/HTTPS 위에서 동작
상태 관리	Stateful / Stateless 모두 지원	기본적으로 Stateless를 지향 (각 요청이 독립적)
보안 메커니즘	자체 내장 보안 (WS-Security, 엔터프라이즈급)	전송 계층 보안 (HTTPS) 및 토큰(OAuth, JWT) 의존
캐싱 (Caching)	HTTP 캐싱을 활용할 수는 있지만 구조상 REST보다 비효율적	HTTP 캐싱 시스템 완벽 지원 (성능 최적화 유리)
학습 곡선	높음 (WSDL, 복잡한 세팅 등 필요)	낮음 (직관적인 URL과 명확한 HTTP 메서드)