[CS] SOAP에서 REST로의 전환의 이유와 장단점

WeeklyPaper: 웹 API의 발전 과정에서 SOAP에서 REST로의 전환이 일어난 이유와 그 장단점에 대해 설명하세요.

---

웹개발을 하다보면 언젠가 마주치는 주제다. SOAP는 무엇이고 REST와는 어떻게 다를까?

 

SOAP와 REST는 두 가지 인터넷 데이터 교환 메커니즘이다. 어플리케이션을 만드려면 다양한 프로그래밍 언어/아키텍쳐/플랫폼을 사용할 수 있는데, 데이터 형식이 서로 다르기 때문에 다양한 기술간 데이터를 공유하는 것이 어려울 수 있다. SOAP와 REST는 모두 이 문제를 해결하기 위해 개발되었다.

 

공통점:

• 둘 다 애플리케이션 간 데이터 요청/처리/응답하는 방식에 대한 규칙과 표준을 설명함 (API 구축)
• 둘 다 HTTP를 사용하여 정보를 교환함
• 둘 다 안전하고 암호화된 통신을 위해 SSL/TLS를 지원함

SOAP (Simple Object Access Protocol)

SOAP는 다른 언어로 다른 플랫폼에서 빌드된 애플리케이션이 통신할 수 있도록 설계된 최초의 표준 프로토콜이다. REST보다 더 많은 표준 (보안 및 메세지 전송 방식 등)을 정의하여 조금 더 복잡하다. 

그래서 이런 기본 제공 표준은 약간 더 많은 오버헤드를 수반하지만, 보안, 트랜색션과 ACID (Atomicity, Consistency, Isolation, Durability) 준수 특면에서 이런 포괄적인 기능이 필요한 회사의 경우 결정적인 요인이 될 수 있다 (엔터프라이즈에 더 이상적이다).

 

특징

• 엄격한 보안을 제공한다 (WS-Security, WS-ReliableMessaging)
• HTTP 뿐만 아니라 SMTP, FTP 등 다양한 프로토콜로 사용 가능하다
• 안정적인 메시징 기능을 위한 성공/재시도 논리 (REST에는 표준 메시징 시스템이 없고 재시도를 통해서만 통신 실패를 해결할 수 있다)
• ACID 준수가 내장되어있다

장점

• 높은 보안
• 엄격한 표준 기반 (REST는 표준이 없음)
• 트랜잭션 + 메세지 신뢰성 보장

단점

• 무겁고 구조가 복잡하다 (XML 기반)
• 과도한 오버헤드 (작은 데이터 전송에도 많은 정보 포함)
• 높은 진입장벽

REST (Representational State Transfer)

표준을 정하지 않은 아키텍쳐 스타일이다. 가이드라인이기 때문에 이러한 권장 사항의 구현 여부는 개발자에게 달려 있다.

일반적으로 JSON이 가장 많이 사용되지만, XML, YAML, 등 다양한 형태를 사용할 수 있다. 사용하는 방식은 먼저 URI로 자원에 접근하고, HTTP 메서드(GET, POST, PUT, DELETE) 를 사용하여 자원을 관리한다.

 

REST API는 보기만 해도 목적이 명확하다:

GET /messages/10 // get message number 10
GET /messages // get all messages
DELETE /messages/12 // delete message number 12

• GET: 자원 조회
• POST: 새 자원 추가
• PUT: 자원 전체 갱신
• PATCH: 자원 변경 (부분 갱신)
• DELETE: 삭제

장점

• JSON 사용 (경량 구조)
• 캐싱 가능
• 진입장벽 낮음
• 명확한 URI 구조와 HTTP 메서드 사용 (이해가 쉬움)

단점

• 복접한 보안 처리
• 트랜잭션과 상태 관리 등은 어플리케이션 레벨에서 처리해야함

차이점 정리

	SOAP (Simple Object Access Protocol)	REST (Representational State Transfer)
무엇인가요?	애플리케이션 간 통신을 위한 프로토콜	통신 인터페이스를 설계하기 위한 아키텍처 스타일
설계	SOAP API는 작업을 노출	REST API는 데이터를 노출
전송 프로토콜	독립적이고 모든 전송 프로토콜과 함께 작동할 수 있음 (HTTP, SMTP, FTP 등)	REST는 HTTPS에서만 작동함
데이터 형식	XML 데이터 교환만 지원함	XML, JSON, 일반 텍스트, HTML을 지원함
성능	메시지가 커서 통신 속도가 느려짐	작은 메시지와 캐싱 지원으로 인해 성능이 더 빠름
확장성	확장 어려움 - 서버는 클라이언트와 교환한 이전 메시지를 모두 저장하여 상태를 유지함	확장 쉬움 - 무상태 방식이므로 모든 메시지가 이전 메시지와 독립적으로 처리됨
보안	추가 오버헤드가 있는 암호화를 지원함, WS-Security - 전송 레벨에서 아주 뛰어나며 SSL보다도 조금 더 복잡하기 때문에 기업용 보안 도구에 통합하는데 이상적임	성능에 영향을 주지 않고 암호화를 지원함
사용 사례	레거시 애플리케이션 / 프라이빗 API에서 유용함	최신 애플리케이션 / 공개 API에서 유용함
캐시	불가능함	가능함

 

왜 REST로 전환되었는가?

SOAP

• 위의 차이점을 읽어보면 SOAP는 어렵고 무겁고 느리다는 것을 볼 수 있고, 복잡한 구도로 인해 오버헤드가 있으며 이는 SOAP의 확장성을 저해하고 있다는 것을 볼 수 있다. 또한 개발 난이도가 높은 편이기도 하다.
• 대부분의 레거시 시스템에서 SOAP를 준수한다. 은행용 모바일 앱처럼 보안수준이 높아야하거나, ACID를 꼭 준수해야하는 경우라면 SOAP 방식이 선호되지만, 그 외 경우에는 RESTful API가 선호된다.
  • 예시) 엔터프라이즈 통합 시스템, 금융 거래, B2B 시스템 등

REST

• REST는 플랫폼, 프로그래밍에 독립적이고 가볍고 빠르다. 그리고 무엇보다 개발하기가 쉽고 SOAP와 달리 학습곡선이 SOAP에 비해서 훨씬 낮다.
• 스마트폰 개발을 하게 되면서 급속도로 RESTful API 사용이 많아졌고, 백엔드와 프론트엔드가 분리 되면서 RESTful하게 개발하는 사례가 자연스럽게 늘어났다.
• 또한 REST는 구조상 확장성과 유지보수에 용이하고, 마이크로서비스나 클라우드같은 다양한 환경과 궁합이 좋아서 많이 사용되고 있다.

 

자료

• https://aws.amazon.com/ko/compare/the-difference-between-soap-rest/

SOAP와 REST 비교 - API 기술 간의 차이점 - AWS

• https://www.redhat.com/ko/topics/integration/whats-the-difference-between-soap-rest

REST vs SOAP: 개념, 특징, 차이점, 장단점 이해하기 쉽게 비교

• https://gogetem.tistory.com/entry/REST-API-vs-SOAP-API-%EC%A0%95%EC%9D%98%E3%85%A3%EC%B0%A8%EC%9D%B4-%EC%99%84%EB%B2%BD%EC%A0%95%EB%A6%AC

REST API vs SOAP API 정의ㅣ차이 완벽정리