사붐이개발일기
REST 와 SOAP 본문
SOAP와 REST의 차이점
SOAP와 REST는 두 가지 인터넷 데이터 교환 메커니즘입니다. 예를 들어 내부 계정 시스템이 고객의 회계 시스템과 데이터를 공유하여 인보이스 발행 작업을 자동화한다고 가정해 보겠습니다. 두 애플리케이션은 통신 규칙을 정의하는 API를 사용하여 데이터를 공유합니다. SOAP와 REST는 API 설계에 대한 두 가지 다른 접근 방식입니다. SOAP 접근 방식은 고도로 구조화되어 있으며 XML 데이터 형식을 사용합니다. REST는 더 유연하며 애플리케이션에서 다양한 형식으로 데이터를 교환할 수 있습니다.
개요
REST와 SOAP는 온라인 데이터 전송에 대한 서로 다른 두 가지 접근 방식입니다. 특히 둘다 웹 애플리케이션 간에 데이터를 통신할 수 있도록 하는 API(애플리케이션 프로그래밍 인터페이스)를 구축하는 방법을 정의합니다. REST(Representational State Transfer)는 일련의 아키텍처 원칙입니다. SOAP(Simple Object Access Protocol)는 W3C(World wide Web Consortium)에서 관리하는 공식 프로토콜입니다. 주요 차이점은 SOAP는 프로토콜이고 REST는 그렇지 않다는 것입니다. 일반적으로 API는 사용 사례 및 개발자의 기본 설정에 따라 REST 또는 SOAP를 준수합니다.
REST: 표현 상태 전송
REST는 경량 웹 서비스 및 모바일 애플리케이션의 요구사항에 맞는 일련의 아키텍쳐 원칙입니다. 일련의 지침이기 때문에 이러한 권장 사항의 구현은 개발자에게 맡깁니다.
데이터 요청이 REST API로 전송될 때 일반적으로 하이퍼텍스트 전송 프로토콜(HTTP)을 통해 수행됩니다. 요청이 수신되면 REST용으로 설계된 API(RESTful API)는 HTML, XML, 일반 텍스트 및 JSON과 같은 다양한 형식으로 메시지를 반환할 수 있습니다. JSON(JavaScript 객체 표기법)은 이름에도 불구하고 모든 프로그래밍언어로 읽을 수 있고 사람과 기계가 읽을 수 있으며 가볍기 때문에 메시지 형식으로 선호됩니다. 이러한 방식으로 RESTful API는 더 유연하고 설정하기가 더 쉽습니다.
애플리케이션이 6가지 아키텍쳐 지침을 따르는 겨우 RESTful이라고 합니다. RESTful 애플리케이션에는 다음이 있어야 합니다.
1. 클라이언트, 서버 및 리소스로 구성된 클라이언트-서버 아키텍쳐입니다.
2. 상태 비저장 클라이언트-서버 통신은 클라이언트 콘텐츠가 요청 사이에 서버에 저장되지 않음을 의미합니다. 대신 세션 상태에 대한 정보가 클라이언트에 보관됩니다.
3. 일부 클라이언트-서버 상호 작용의 필요성을 제거하기 위해 캐시 가능한 데이터
4. 정보가 응용 프로그램의 요구사항에 한정되지 않고 표준화된 형식으로 전송되도록 하는 구성요소 간의 균일한 인터페이스입니다. 이는 REST의 창시자인 Roy Fielding이 "REST 아키텍쳐 스타일을 다른 네트워크 기반 스타일과 구별하는 핵심 기능"이라고 설명합니다.
5. 클라이언트-서버 상호작용이 계층적 계층에 의해 조정될 수 있는 계층화된 시스템 제약조건입니다.
6. 주문형 코드: 실행 가능한 코드를 전송하여 서버가 클라이언트의 기능을 확장할 수 있도록 합니다(가시성도 감소하므로 선택적 지침이 됨).
SOAP: 단순 개체 액세스 프로토콜
SOAP는 서로 다른 플랫폼에서 서로 다른 언어로 구축된 응용 프로그램이 통신할 수 있도록 처음 설계된 표준 프로토콜입니다. 프로토콜이기 때문에 복잡성과 오버헤드를 증가시키는 기본 제공 규칙을 적용하여 페이지 로드 시간이 길어질 수 있습니다. 그러나 이러한 표준은 엔터프라이즈 시나리오에 적합하도록 기본 제공 규정 준수도 제공합니다. 내장된 규정 준수표준에는 안정적인 데이터베이스 트랜잭션을 보장하기 위한 속성 집합인 보안, 원자성, 일관성, 격리 및 내구성(ACID)이 포함됩니다.
일반적인 웹 서비스 사양은 다음과 같습니다.
- 웹 서비스 보안(WS-security): 토큰이라는 고유 식별자를 통해 메시지를 보호하고 전송하는 방법을 표준화합니다.
- WS-ReliableMessaging: 신뢰할 수 없는 IT 인프라를 통해 전송되는 메시지 간의 오류 처리를 표준화합니다.
- 웹 서비스 주소 지정(WS-addressing): 라우팅 정보를 네트워크 내에서 더 깊게 유지하는 대신 SOAP 헤더 내의 메타데이터로 패키징합니다.
- WSDL(웹 서비스 기술 언어): 웹 서비스가 수행하는 작업과 해당 서비스가 시작되고 끝나는 위치를 설명합니다.
데이터 요청이 SOAP API로 전송되면 HTTP(웹 브라우저용), SMTO(이메일용), TCP 등의 애플리케이션 계층 프로토콜을 통해 처리할 수 있습니다. 그러나 일단 요청을 받으면 반환 SOAP 메시지는 사람과 기계가 모두 읽을 수 있는 마크업 언어인 XML 문서로 반환되어야 합니다. SOAP API에 대한 완료된 요청은 브라우저에서 캐시할 수 없으므로 API로 다시 보내지 않고는 나중에 액세스할 수 없습니다.
SOAP vs REST
많은 레거시 시스템은 여전히 SOAP를 고수할 수 있지만 REST는 나중에 등장했으며 종종 웹 기반 시나리오에서 더 빠른 대안으로 간주됩니다. REST는 유연한 구현을 제공하는 일련의 지침인 반면 SOAP는 XML 메시징과 같은 특정 요구 사항이 있는 프로토콜입니다.
REST API는 가볍기 때문에 사물 인터넷(IoT), 모바일 애플리케이션 개발 및 서버리스 컴퓨팅과 같은 새로운 컨텍스트에 이상적입니다. SOAP 웹 서비스는 많은 엔터프라이즈 요구사항에 부합하는 기본 제공 보안 및 트랜잭션 규정 준수를 제공하지만 이로 인해 더 무거워집니다. 또한 Google Maps API와 같은 많은 공개 API는 REST 지침을 따릅니다.
참고자료
soap 와 rest 비교: https://aws.amazon.com/ko/compare/the-difference-between-soap-rest/
rest vs soap : https://www.redhat.com/en/topics/integration/whats-the-difference-between-soap-rest
