[네트워크] SOAP과 REST의 차이

1. SOAP이란?

SOAP(Simple Object Access Protocol)은 XML 기반의 통신 표준으로 2000년대 초반 웹 서비스를 지배했다.

 

장점

• 기존 원격 기술들에 비해서 프록시와 방화벽에 구애받지 않고 쉽게 통신 가능합니다.
• 플랫폼과 프로그래밍 언어에 독립적입니다.
• 웹 서비스를 제공하기 위한 표준(WSDL = 문서 명세)이 잘 정립되어 있습니다.
• 에러 처리에 대한 내용이 기본으로 내장되어 있습니다.
• 분산 환경에 적합합니다.

 

단점

• 복잡한 구조⭐로 인해 오버헤드가 있으며, 이는 SOAP의 확장을 저해하고 있습니다.
• REST에 비해 상대적으로 무겁고 속도도 느립니다.⭐⭐
• 개발 난이도가 높아⭐ 개발 환경의 지원이 필요합니다.

 

1-1. SOAP 예시 코드

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" 
               soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

    <soap:Header>
        ...
    </soap:Header>

    <soap:Body>
        ...
        <soap:Fault>
            ... 
        </soap:Fault>
    </soap:Body>

</soap:Envelope>

• Envelope: 전체 메시지를 감싸는 루트 요소
• Header: 인증 등 메타데이터 구역
• Body: 실제 데이터가 들어가는 구역
• Fault: 에러 발생 시 정보를 담는 구역

 

1-2. SOAP/WSDL 분석

1. 강력한 명세 (WSDL): 코드 작성법과 데이터 규격이 XML로 엄격하게 정의되어 있어, 대규모 협업 시 오류 없는 연동이 가능할 것 같다.
2. 표준화된 에러 처리: Fault 요소를 통해 내부적으로 규격화된 에러 메시지를 주고받을 수 있는 안정성을 갖췄다.
3. 가독성 및 효율성 리스크(⭐ ⭐ ): 하지만 현대의 REST/JSON 방식에 비해 구조가 너무 복잡하고 가독성이 낮아, 빠른 개발과 가벼운 통신이 중요한 현대 웹 시장에서는 외면받을 수밖에 없다.

---

2. REST란?

REST(Representational State Transfer)란 특정 기술의 이름이 아니고 일종의 설계 철학, 또는 아키텍쳐 스타일을 뜻한다.

1. Client-Server(클라이언트-서버 구조): 자원을 제공하는 서버와 요청하는 클라이언트의 역할을 명확히 분리하여 독립적인 발전을 가능하게 함.
2. Stateless(무상태성): 서버는 클라이언트의 상태를 저장하지 않으며, 각 요청은 독립적으로 처리됨.
3. Cache(캐시 처리 가능): 캐싱 기능을 활용하여 서버의 부하를 줄이고 응답 속도를 높임.
4. Uniform Interface(일관된 인터페이스): 자원(URI) 지정, 조작 방식 등이 표준화되어 플랫폼에 상관없이 동일한 방식으로 통신함.
5. Layered System(계층화 시스템): 클라이언트는 대상 서버와 직접 통신하는지, 중간 서버(보안, 로드 밸런싱)를 거치는지 알 수 없도록 계층화함.
6. Self-descriptiveness(자체 표현 구조): 메시지 내용만 보고도 해당 요청이 무엇을 의미하는지, 어떤 데이터를 담고 있는지 스스로 설명할 수 있어야 함.

 

장점

• HTTP 표준과 상성이 좋아서 그대로 사용하므로 별도의 추가 인프라 구축이 필요 없습니다.
• 브라우저의 사용 확대가 되면서 HTTP통신이 대중화되고 그로인해 브라우저의 Javascript기술도 대중화가 되어서 JSON 기반의 통신이 주를 이루고 JSON은데이터 크기가 작고 가독성이 매우 높습니다. ⭐ ⭐
• Stateless(무상태성) 특성을 가져 서버의 확장성이 뛰어나고 분산 시스템에 유리합니다.
• 다양한 브라우저와 플랫폼에서 별도의 라이브러리 없이 쉽게 호출 가능합니다.
• 서비스 자원(URI)을 중심으로 설계되어 직관적이고 배우기 쉽습니다.⭐

 

단점

• 표준의 부재⭐로 인해 개발자나 기업마다 설계 방식이 제각각일 수 있습니다. (엄격한 규격 부족)
• HTTP 메서드(GET, POST 등)의 한계로 인해 복잡한 기능 구현 시 설계가 모호해질 수 있습니다.
• SOAP에 비해 메시지 수준의 보안 표준(WS-Security 등)이 부족하여 별도의 보안 처리가 필요합니다.
• 구형 브라우저나 특정 환경에서는 일부 메서드(PUT, DELETE 등) 사용에 제약이 있을 수 있습니다.

 

2-1. REST(설계 철학)를 지킨 HTTP 통신 예시

메서드	엔드포인트(URI)	역할 (CRUD)	설명
GET	/users	Read (목록)	전체 사용자 목록 조회
GET	/users/{id}	Read (단일)	특정 ID 사용자 상세 정보 조회
POST	/users	Create	새로운 사용자 생성 (회원가입)
PUT	/users/{id}	Update (전체)	사용자 정보 전체 수정 및 교체
PATCH	/users/{id}	Update (일부)	사용자 정보 중 특정 항목만 수정
DELETE	/users/{id}	Delete	특정 사용자 정보 삭제

 

---

3. 현대 개발에 REST API로 넘어간 이유

📝
"기술은 대중성이 생명이다"

1. 많은 사람이 사용하고 시장에서 유명해야 도구(라이브러리)도 많아지고 끝까지 살아남는다.
2. 아무리 기능이 좋아도 배우기 어렵고, 속도가 느리고, 구조가 복잡하면 결국 시장에서 버림받는다.