SOAP 대 REST: 두 가지 다른 API 스타일 살펴보기

SOAP 대 REST: 두 가지 다른 API 스타일 살펴보기

 

SOAP 대 REST: 두 가지 다른 API 스타일 살펴보기

API(응용 프로그래밍 인터페이스) 아키텍처에 대해 이야기할 때 가장 일반적인 두 가지 API 패러다임인 SOAP와 REST를 비교하는 것이 일반적입니다. 이 둘은 종종 사과와 사과로 비교되지만 본질적으로 다른 기술이며 세부적인 수준에서 쉽게 비교되지 않습니다.

왜요? SOAP는 프로토콜이고 REST는 아키텍처 스타일이기 때문입니다. REST API는 HTTP를 사용할 수 있는 것처럼 실제로 SOAP 프로토콜을 사용할 수 있습니다. 따라서 박쥐는 즉시 다르게 패키징되고, 다르게 기능하고, 다른 시나리오에서 사용될 것입니다.

이제 그 문제를 해결했으므로 각각에 대해 조금 더 자세히 살펴보겠습니다. 여기에는 신발이 맞는 경우 응용 프로그램에 서로 사용하고 싶게 만드는 몇 가지 장점이 있습니다.

 

API란 무엇입니까?

가장 간단한 용어로 API는 서버의 특정 부분에 대한 액세스 권한을 부여하여 한 응용 프로그램을 다른 응용 프로그램의 데이터 및 서비스에 직접 연결하는 소프트웨어입니다. API는 두 개의 소프트웨어가 통신할 수 있도록 하며 대부분의 최신 애플리케이션의 기반입니다. 이를 통해 IT 아키텍처를 간소화하고 마케팅 워크플로를 자동화하며 데이터 세트를 더 쉽게 공유할 수 있습니다.

 

REST API란 무엇입니까?

REST(Representational State Transfer)는 진정한 "웹 서비스" API입니다. REST API는 URI(Uniform Resource Identifier, URL이 특정 유형) 및 HTTP 프로토콜을 기반으로 하며 슈퍼 브라우저와 호환되는 데이터 형식에 JSON을 사용합니다. (위에서 언급한 것처럼 이론적으로 SOAP 프로토콜을 사용할 수도 있습니다.) REST API는 구축 및 확장이 간단할 수 있지만 거대하고 복잡할 수도 있습니다. 그들은 할 수 있도록 설계되었습니다.

API를 RESTful로 구축하려는 이유에는 리소스 제한, 보안 요구 사항 감소, 브라우저 클라이언트 호환성, 검색 가능성, 데이터 상태 및 확장성(웹 서비스에 실제로 적용되는 사항)이 포함됩니다.

 

몇 가지 빠른 REST 정보:

• REST는 HTTP 프로토콜 덕분에 간단합니다.
• REST API는 클라이언트-서버 통신 및 아키텍처를 용이하게 합니다. RESTful인 경우 이 클라이언트-서버 원칙을 기반으로 하며 전달되는 두 정보 페이로드 간에 왕복 이동이 가능합니다.
• REST API는 단일 균일 인터페이스를 사용합니다. 이는 애플리케이션이 모두 동일한 포털을 통해 동일한 방식으로 인터페이스하도록 요구함으로써 API와 상호작용하는 방식을 단순화합니다. 이것은 장점과 단점이 있습니다. 
• REST는 웹에 최적화되어 있습니다. JSON을 데이터 형식으로 사용하면 브라우저와 호환됩니다. ‍
• REST는 뛰어난 성능과 확장성으로 유명합니다. 그러나 다른 기술과 마찬가지로 앱이 느려지거나 느려질 수 있습니다. 그래서 REST로도 해결할 수 없는 문제를 해결하기 위해 GraphQL과 같은 언어가 등장했습니다.

 

SOAP이란 무엇입니까?

SOAP(Simple Object Access Protocol)는 자체 프로토콜이며 REST보다 더 많은 표준(보안 및 메시지 전송 방식 등)을 정의하여 조금 더 복잡합니다. 이러한 기본 제공 표준은 약간 더 많은 오버헤드를 수반합니다. 그러나 보안, 트랜잭션 및 ACID(Atomicity, Consistency, Isolation, Durability) 준수 측면에서 보다 포괄적인 기능이 필요한 조직의 경우 결정적인 요소가 될 수 있습니다. 이 비교를 위해 SOAP가 좋은 선택인 많은 이유는 웹 서비스 시나리오에 거의 적용되지 않으므로 엔터프라이즈 유형 상황에 더 이상적이라는 점을 지적해야 합니다.

 

SOAP API를 사용 하여 애플리케이션 을 개발 하려는 이유 에는 더 높은 수준의 보안(예: 은행과 인터페이스하는 모바일 애플리케이션), 안정적인 통신이 필요한 메시징 앱, 레거시 시스템과의 통신 또는 ACID 준수가 포함됩니다.

• SOAP는 훨씬 더 엄격한 보안을 가지고 있습니다. SSL 지원 외에도 WS-Security는 필요한 경우 SOAP에 더 많은 엔터프라이즈 수준 보안 기능을 제공하는 기본 제공 표준입니다.
• 안정적인 메시징 기능을 위한 성공/재시도 논리. REST에는 표준 메시징 시스템이 없으며 재시도를 통해서만 통신 실패를 해결할 수 있습니다. SOAP에는 성공/재시도 논리가 내장되어 있으며 SOAP 중개자를 통해서도 종단 간 안정성을 제공합니다.
• SOAP에는 ACID 준수가 내장되어 있습니다. ACID 준수는 트랜잭션이 데이터베이스와 상호 작용할 수 있는 방법을 규정하여 이상을 줄이고 데이터베이스의 무결성을 보호합니다. ACID는 다른 데이터 일관성 모델보다 보수적이므로 일반적으로 재무 또는 기타 민감한 거래를 처리할 때 선호됩니다.

 

SOAP 대 REST 예

SOAP와 REST 간의 실질적인 차이점을 더 잘 이해하기 위해 두 기술을 사용하여 동일한 작업을 수행하는 방법의 예를 만들었습니다. 이 예에서는 사용자 세부 정보를 요청하고 있습니다.

SOAP 예제

SOAP를 사용하는 API에 대한 요청은 XML 요청 본문이 있는 HTTP POST 요청입니다. 요청 본문은 요청된 API를 식별하는 SOAP 래퍼 유형인 봉투와 요청 매개변수를 보유하는 SOAP 본문으로 구성됩니다. 이 경우 "John"이라는 이름의 사용자를 가져오려고 합니다.

 

 

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"xmlns:sch="http://www.soapexample.com/xml/users">

   <soapenv:Header/>

   <soapenv:Body>

      <sch:UserDetailsRequest>

          <sch:name>John</sch:name>

      </sch:UserDetailsRequest>

   </soapenv:Body>

 </soapenv:Envelope>

‍

응답은 요청과 마찬가지로 SOAP Envelope와 SOAP Body으로 구성됩니다. 이 경우 SOAP Body은 요청된 사용자 데이터를 나타냅니다.

 

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">

   <soapenv:Header/>

   <soapenv:Body>

      <ns2:UserDetailsResponse xmlns:ns2="http://www.soapexample.com/xml/users">

      <ns2:User>

      <ns2:name>John</ns2:name>

      <ns2:age>5</ns2:age>

      <ns2:address>Greenville</ns2:address>

      </ns2:User </ns2:UserDetailsResponse>

   </soapenv:Body>

</soapenv:Envelope>

‍‍

REST 예제

REST API는 모든 HTTP 동사로 호출할 수 있습니다. 리소스를 가져오기 위해 이 경우 사용자, GET 요청이 사용됩니다. SOAP 요청이 본문에 사용자 이름을 보유하는 동안 REST API는 URI에서 GET 매개변수를 허용합니다.

GET https://restexample.com/users?name=John

언급했듯이 REST API는 일반적으로 데이터 형식 JSON을 사용합니다. 사용자는 다음과 같이 JSON으로 표시됩니다.

 

{

 "name": "John",

 "age": 5,

 "address": "Greenville"

}

‍

 

SOAP 대 REST: 주요 차이점

아래에서 두 패러다임 간의 몇 가지 주요 차이점을 살펴보겠습니다.

 

SOAP는 프로토콜인 반면 REST는 아키텍처 스타일입니다.

API는 서버에서 애플리케이션 비즈니스 로직의 특정 측면을 노출하도록 설계되었으며 SOAP은 서비스 인터페이스를 사용하여 이를 수행하는 반면 REST는 URI를 사용합니다. SOAP API는 API가 노출하는 기능 이후에 설계되지만 REST API는 데이터 이후에 설계됩니다. 

 

예를 들어, 사용자를 생성하는 기능을 노출하는 SOAP API에는 SOAP 본문에 지정되는 "CreateUser"라는 함수가 포함될 수 있습니다. REST API는 대신 URL /users를 노출하고 해당 URL에 대한 POST 요청은 사용자를 생성합니다.

 

REST API는 데이터 리소스(URI)에 액세스합니다. SOAP API는 작업을 수행합니다.

REST는 보다 데이터 중심적인 아키텍처인 반면 SOAP는 보다 기능 중심적인 구조화된 정보를 전송하기 위한 표준화된 프로토콜입니다. 

REST는 일반 텍스트, HTML, XML 및 JSON을 포함한 다양한 데이터 형식을 허용하며, 이는 데이터에 매우 적합하고 더 많은 브라우저 호환성을 제공합니다. 

SOAP는 XML만 사용합니다.

SOAP API는 위의 예에서 본 것처럼 XML과 SOAP 봉투, 헤더 및 본문을 포함하는 형식을 사용하는 것으로 제한됩니다. 

그러나 REST API는 형식에 구애받지 않습니다. 가장 일반적인 형식은 JSON이지만 XML, 일반 텍스트 및 XML과 같은 형식도 REST API에 유효합니다.

 

보안은 다르게 처리됩니다.

SOAP는 전송 수준에서 훌륭하고 SSL보다 약간 더 포괄적이며 엔터프라이즈 수준 보안 도구와의 통합에 더 이상적인 WS-Security를 ​​지원합니다. 둘 다 종단 간 보안을 위해 SSL을 지원하고 REST는 HTTP 프로토콜인 HTTPS의 보안 버전을 사용할 수 있습니다. SOAP 및 REST API 모두 HTTPS 및 SSL을 사용하여 통신을 암호화할 수 있지만 SOAP에서 제공하는 WS-Security의 추가 계층은 메시지 수준에서 작동하여 올바른 서버에서 메시지 내용을 읽을 수 있을 뿐만 아니라 서버의 올바른 프로세스.

SOAP에는 더 많은 대역폭이 필요하지만 REST에는 더 적은 리소스가 필요합니다(API에 따라 다름)

SOAP를 사용하는 경우 오버헤드가 조금 더 있습니다. REST는 주로 웹 서비스에 사용되기 때문에 가볍다는 것이 장점입니다.

이전 섹션의 예제 SOAP 요청에서 볼 수 있듯이 SOAP 요청에는 REST 요청보다 더 많은 데이터가 포함됩니다. 이것은 SOAP API와 통신할 때 더 많은 대역폭이 사용된다는 것을 의미합니다. 이는 트래픽 양이 많은 시스템에 영향을 줄 수 있습니다.

 

REST 호출은 캐시할 수 있지만 SOAP 기반 호출은 캐시할 수 없습니다.

데이터는 캐시 가능으로 표시될 수 있습니다. 즉, 나중에 서버에 대한 다른 요청을 다시 시작하지 않고도 브라우저에서 데이터를 재사용할 수 있습니다. 이렇게 하면 시간과 리소스가 절약됩니다. 모든 SOAP 요청은 POST 요청을 사용하여 전송되고 POST 요청은 HTTP 표준에 의해 멱등성이 아닌 것으로 간주되므로 응답은 HTTP 수준에서 캐시되지 않습니다. REST API에는 이러한 제한이 없지만 캐싱을 사용하려면 캐싱 메커니즘을 직접 구현해야 합니다. 캐싱은 성능과 확장성이 중요한 역할을 할 때 핵심 기능입니다.

 

API는 앱의 페이로드를 처리하도록 구축되었으며 REST와 SOAP는 이를 다르게 수행합니다.

페이로드(payload)는 인터넷을 통해 전송되는 데이터이며 페이로드가 "무거워"지면 더 많은 리소스가 필요합니다. REST는 페이로드를 줄이는 HTTP 및 JSON을 사용하는 경향이 있습니다. SOAP는 XML에 더 의존합니다.

 

SOAP API에는 매우 엄격한 통신 계약이 있으며 일반적으로 클라이언트는 생성된 코드가 있는 특정 클라이언트 라이브러리를 사용하여 액세스해야 합니다. 이것은 SOAP가 서버와 밀접하게 결합되어 REST에 비해 더 낮은 추상화 계층을 제공한다는 것을 의미합니다. 두 기술 간의 추상화 수준이 높을수록 상호 작용에 대한 통제력이 떨어집니다. 그래도 복잡성이 덜하고 전체 관계를 깨뜨리지 않고 둘 중 하나를 업데이트하는 것이 더 쉽습니다. 이것이 SOAP와 REST 간의 주요 차이점입니다. 

 

SOAP는 서버와 매우 밀접하게 연결되어 있어 서버와의 엄격한 통신 계약으로 인해 변경 또는 업데이트를 수행하기가 더 어렵습니다. 

 

REST API와 상호 작용하는 클라이언트는 API에 대한 지식이 필요하지 않습니다. 

 

개발 관점에서 SOAP 클라이언트는 일반적으로 SOAP API와 통신하기 위해 타사 라이브러리가 필요합니다. 대조적으로 REST API와 통신하는 데 필요한 유일한 라이브러리는 일반적으로 프로그래밍 언어에 내장된 HTTP 요청 라이브러리입니다.

 

SOAP 및 REST 대안

SOAP 및 REST는 지난 수십 년 동안 API 구축을 위한 주요 선택이었지만 다른 대안이 점점 더 일반화되고 있습니다.

JSON

JSON(JavaScript Object Notation)은 많은 응용 프로그램 간에 데이터 개체를 전송하는 데 사용되는 개방형 표준 파일 형식입니다. 데이터를 저장하고 전송하는 경량 형식으로 서버에서 웹 페이지로 데이터를 보낼 때 자주 사용됩니다. SOAP의 단순성과 더 빠른 전송은 많은 상황에서 실행 가능한 대안이 됩니다.

gRPC

gRPC(Remote Procedure Call)는 HTTP/2 를 사용하는 Google에서 개발한 오픈 소스 시스템입니다 . 일반적으로 마이크로 서비스 아키텍처에서 서비스를 연결하고 모바일 장치를 백엔드 서비스에 연결하는 데 사용됩니다. gRPC의 장점에는 JSON보다 가벼운 메시지, 고성능, 기본 제공 코드 생성, 스트리밍 데이터와 같은 더 많은 연결 옵션 지원이 있습니다.

GraphQL

GraphQL은 일반적으로 서버에서 클라이언트로 데이터를 로드하는 데 사용되는 쿼리 언어이지만 매우 효율적입니다. Facebook에서 만든 이 비교적 새로운 기술은 읽기, 쓰기 및 데이터 변경 사항 구독을 지원하며 GraphQL 서버는 JavaScript, Python, C++ 등과 같은 언어에서 사용할 수 있습니다.

REST와 마찬가지로 GraphQL은 HTTP를 사용하여 통신하고 JSON 데이터 형식을 사용합니다. 주요 차이점과 이점 중 하나는 한 번의 API 호출로 서버에서 반환하려는 데이터를 지정할 수 있다는 것입니다. 예를 들어 REST를 사용하여 고객, 고객 주문 및 주문 배송 상태를 가져오려면 각 데이터에 대해 별도의 HTTP 요청을 수행해야 합니다. GraphQL을 사용하면 하나의 요청으로 모든 것을 가져올 수 있으므로 각 호출에 대한 HTTP 오버헤드가 제거됩니다. ‍

 

프로젝트에 어떤 API를 선택해야 하나요?

대부분의 경우 웹 서비스용 API와 관련하여 개발자는 SOAP 경로가 더 나은 선택이 아닌 한 RESTful 아키텍처를 선호하는 경향이 있습니다. 

 

 

REST API를 선택할 때의 추가 이점은 다음과 같습니다.

• HTTP 및 작은 페이로드(예: JSON 데이터 형식)를 사용한 경량 통신
• 클라이언트 측 외부 라이브러리에 대한 요구 사항 감소
• 효과적인 캐싱 사용 가능

그러나 다음을 포함하여 SOAP가 첫 번째 선택일 수 있는 경우가 있습니다.

• 보안에 대한 엔터프라이즈 수준 요구 사항
• 이미 SOAP를 사용하고 있는 레거시 시스템과 통합해야 함
• ACID 트랜잭션에 대한 요구 사항 또는 SOAP가 제공하는 내장 재시도 메커니즘 사용

어떤 기술을 사용하든 좋은 API를 구축하는 데 가장 중요한 부분은 모범 사례를 사용하여 클라이언트가 쉽게 사용하고 이해할 수 있도록 설계하는 것입니다. 잘 설계된 API는 전송 속도를 크게 높이고 기술 스택의 미래 경쟁력을 높일 수 있습니다.

 

참고사이트 : https://www.upwork.com/resources/soap-vs-rest-a-look-at-two-different-api-styles