SOAP와 REST API: 웹 서비스의 차이점

SOAP와 REST의 차이점

각 기술에는 고유한 장점과 단점이 있습니다. 따라서 각 디자인을 어떤 상황에서 사용해야 하는지 이해하는 것이 항상 좋습니다. 이 REST 및 SOAP API 차이점 튜토리얼에서는 REST와 SOAP API 간의 주요 차이점과 이를 사용하는 동안 발생할 수 있는 문제에 대해 설명합니다.
다음은 SOAP와 REST API의 주요 차이점입니다.

<?xml version="1.0"?>
<SOAP-ENV:Envelope 
xmlns:SOAP-ENV
="http://www.w3.org/2001/12/soap-envelope" 
SOAP-ENV:encodingStyle
=" http://www.w3.org/2001/12/soap-encoding">
<soap:Body>
 <Demo.guru99WebService
 xmlns="http://tempuri.org/">
   <EmployeeID>int</EmployeeID>
   </Demo.guru99WebService>
 </soap:Body>
</SOAP-ENV:Envelope>

{"city":"Mumbai","state":"Maharastra"}

REST는 언제 사용합니까?

가장 논쟁의 여지가 있는 주제 중 하나는 웹 서비스를 설계하는 동안 언제 REST를 사용해야 하는지, 아니면 언제 SOAP를 사용해야 하는지입니다. 다음은 웹 서비스에 REST 및 SOAP API 기술을 사용해야 하는 시기를 결정하는 몇 가지 주요 요소입니다. REST 서비스는 다음의 경우에 사용해야 합니다.

• 제한된 리소스 및 대역폭 – SOAP 메시지는 내용이 더 많고 훨씬 더 많은 대역폭을 소비하므로 네트워크 대역폭이 제약이 되는 경우에는 REST를 사용해야 합니다.
• 무국적자 – 한 요청에서 다른 요청까지 정보 상태를 유지할 필요가 없으면 REST를 사용해야 합니다. 한 요청의 일부 정보가 다른 요청으로 흘러야 하는 적절한 정보 흐름이 필요한 경우 SOAP가 해당 목적에 더 적합합니다. 모든 온라인 구매 사이트를 예로 들 수 있습니다. 이러한 사이트에서는 일반적으로 사용자가 먼저 장바구니에 구매해야 하는 항목을 추가해야 합니다. 그런 다음 구매를 완료하기 위해 모든 장바구니 항목이 결제 페이지로 전송됩니다. 이것은 상태 기능이 필요한 애플리케이션의 예입니다. 추가 처리를 위해 장바구니 항목의 상태를 결제 페이지로 전송해야 합니다.
• 캐싱 – 많은 요청을 캐시해야 하는 경우 REST가 완벽한 솔루션입니다. 때때로 클라이언트는 동일한 리소스를 여러 번 요청할 수 있습니다. 이로 인해 서버로 전송되는 요청 수가 늘어날 수 있습니다. 캐시를 구현하면 가장 빈번한 쿼리 결과를 중간 위치에 저장할 수 있습니다. 따라서 클라이언트가 리소스를 요청할 때마다 먼저 캐시를 확인합니다. 리소스가 존재하는 경우 서버로 진행되지 않습니다. 따라서 캐싱은 웹 서버로 이동하는 횟수를 최소화하는 데 도움이 될 수 있습니다.
• 코딩 용이성 – REST 서비스 코딩 및 후속 구현이 SOAP보다 훨씬 쉽습니다. 따라서 웹 서비스에 빠른 승리 솔루션이 필요한 경우 REST를 사용하는 것이 좋습니다.

다음으로 이 SOAP 및 REST 차이점 튜토리얼에서는 SOAP API를 언제 사용해야 하는지 알아봅니다.

SOAP는 언제 사용합니까?

다음의 경우에는 SOAP를 사용해야 합니다.

1. 비동기 처리 및 후속 호출 – 클라이언트가 보장된 수준의 신뢰성과 보안을 필요로 하는 경우 SOAP 1.2의 새로운 SOAP 표준은 특히 보안과 관련하여 많은 추가 기능을 제공합니다.
2. 공식적인 의사소통 수단 – 클라이언트와 서버가 모두 교환 형식에 동의한 경우 SOAP 1.2는 이러한 유형의 상호 작용에 대해 엄격한 사양을 제공합니다. 예를 들어 사용자가 결제가 이루어지기 전에 장바구니에 항목을 추가하는 온라인 구매 사이트가 있습니다. 최종 결제를 수행하는 웹 서비스가 있다고 가정해 보겠습니다. 웹 서비스가 장바구니 항목 이름, 단가 및 수량만 허용한다는 확고한 합의가 있을 수 있습니다. 그러한 시나리오가 존재한다면 항상 SOAP 프로토콜을 사용하는 것이 더 좋습니다.
3. 상태 저장 작업 – 애플리케이션에 한 요청에서 다른 요청까지 상태를 유지해야 한다는 요구 사항이 있는 경우 SOAP 1.2 표준은 이러한 요구 사항을 지원하기 위해 WS* 구조를 제공합니다.

다음으로 REST와 SOAP API의 차이점에서는 SOAP API의 과제에 대해 알아봅니다.

SOAP API의 과제

API는 다음과 같이 알려져 있습니다. 응용 프로그램 프로그래밍 인터페이스 클라이언트와 서버 모두에서 제공됩니다. 클라이언트 세계에서는 이것이 브라우저에 의해 제공되는 반면, 서버 세계에서는 SOAP 또는 REST일 수 있는 웹 서비스에 의해 제공됩니다.

SOAP API의 과제

1. WSDL 파일 – SOAP API의 주요 과제 중 하나는 WSDL 문서 자체입니다. WSDL 문서는 클라이언트에게 웹 서비스에서 수행할 수 있는 모든 작업을 알려줍니다. WSDL 문서에는 SOAP 메시지에서 사용되는 데이터 유형과 웹 서비스를 통해 사용할 수 있는 모든 작업과 같은 모든 정보가 포함됩니다. 아래 코드 조각은 샘플 WSDL 파일의 일부일 뿐입니다.

<?xml version="1.0"?>
<definitions name="Tutorial"             
	targetNamespace=http://demo.guru99.com/Tutorial.wsdl             
	xmlns:tns=http://demo.guru99.com/Tutorial.wsdl             
	xmlns:xsd1=http://demo.guru99.com/Tutorial.xsd            
	xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/
	xmlns="http://schemas.xmlsoap.org/wsdl/"> 

	<types>  
		<schema targetNamespace=http://Demo.guru99.com/Tutorial.xsd
		xmlns="http://www.w3.org/2000/10/XMLSchema">

      	<element name="TutorialNameRequest">    
			<complexType>          
				<all>           
					<element name="TutorialName" type="string"/>         
				</all>       
			</complexType>    
		</element>     
	<element name="TutorialIDRequest">        
		<complexType>          
			<all>           
				<element name="TutorialID" type="number"/>         
			</all>       
		</complexType>      
	</element>   
	</schema>  
</types>	

위의 WSDL 파일에 따르면 TutorialNameRequest 요소의 일부인 String 유형의 "TutorialName"이라는 요소가 있습니다.

이제 비즈니스 요구 사항에 따라 WSDL 파일이 변경되고 TutorialName이 Tutorial이 되어야 한다고 가정해 보겠습니다.Descript이온. 이는 현재 이 웹 서비스에 연결하고 있는 모든 클라이언트가 WSDL 파일의 변경 사항을 수용하기 위해 해당 코드를 변경해야 함을 의미합니다.

이는 클라이언트와 서버 간의 긴밀한 계약이라는 WSDL 파일의 가장 큰 과제와 하나의 변경으로 인해 클라이언트 애플리케이션 전체에 큰 영향을 미칠 수 있음을 보여줍니다.

2. 문서 크기 – 또 다른 주요 과제는 클라이언트에서 서버로 전송되는 SOAP 메시지의 크기입니다. 메시지가 크기 때문에 대역폭이 제한된 장소에서 SOAP를 사용하는 것은 큰 문제가 될 수 있습니다.

다음으로 RESTful과 SOAP의 차이점에서는 REST API의 과제에 대해 알아봅니다.

REST API의 과제

1. 보안 부족 – REST는 SOAP와 같은 어떤 종류의 보안도 적용하지 않습니다. 그렇기 때문에 REST는 공개적으로 사용 가능한 URL에 매우 적합하지만 클라이언트와 서버 간에 기밀 데이터가 전달되는 경우 REST는 웹 서비스에 사용되는 최악의 메커니즘입니다.
2. 상태 부족 – 대부분의 웹 애플리케이션에는 상태 저장 메커니즘이 필요합니다. 예를 들어, 장바구니가 있는 메커니즘을 갖춘 구매 사이트가 있는 경우 실제 구매가 이루어지기 전에 장바구니에 있는 항목 수를 알아야 합니다. 불행하게도 이 상태를 유지하는 부담은 클라이언트에게 있으며, 이로 인해 클라이언트 애플리케이션이 더 무겁고 유지 관리가 어려워집니다.

SOAP와 CORBA, DCOM과의 차이점 Java RMI

RPC와 같은 원격 액세스 기술(원격 프로시저 호출) 메소드는 SOAP 및 REST API가 등장하기 전에 일반적으로 사용되었습니다. 사용 가능한 다양한 원격 액세스 기술은 아래에 언급되어 있습니다.

1. 코바 – 이것은 다음과 같이 알려졌습니다. C옴몬 OBject R승마 B로커 A아키텍처. 이 시스템은 다양한 플랫폼에서 구축된 애플리케이션이 서로 통신할 수 있도록 하기 위해 마련되었습니다. CORBA는 객체 지향 아키텍처를 기반으로 했지만 호출 애플리케이션이 이 아키텍처를 기반으로 할 필요는 없었습니다. 이 기술의 가장 큰 단점은 인터페이스 정의 언어라는 별도의 언어로 개발해야 했고, 개발자가 CORBA 시스템을 사용하기 위해 배워야 하는 추가 언어만 제공했다는 것입니다.
2. DCOM - 이것이 D분배됨 C찬성 OBject M독점 제품인 odel Microsoft 클라이언트가 원격 구성 요소에 액세스할 수 있는 기술입니다. 이 메커니즘의 가장 큰 문제는 더 이상 필요하지 않을 때 리소스를 확보하는 것은 클라이언트 애플리케이션의 몫이라는 것입니다. 둘째, 클라이언트가 요청을 보낼 때 요청이 올바른 방식으로 래핑되거나 마샬링되었는지 확인하는 것은 클라이언트의 몫입니다. 웹 서비스가 전송된 요청을 이해할 수 있도록 하는 것입니다. 또 다른 문제는 클라이언트 애플리케이션이 Java DCOM을 작동해야 했던 기반 애플리케이션(Microsoft 기술) 다른 프로그래밍 언어로 구축된 응용 프로그램이 DCOM 기반 웹 서비스와 작동할 수 있도록 하려면 추가 코딩이 필요했습니다.
3. Java RMI - 로 알려진 Java R감정을 겉으로 나타내다 M에돔 I소환, 이거였어 Java 원격 프로시저 호출을 통해 원격 객체를 호출하는 방법에 대한 구현입니다. 이 기술의 가장 큰 제약은 Java RMI는 다음에서만 실행될 수 있습니다. Java 가상 머신. 이는 호출 애플리케이션도 다음 환경에서 실행되어야 함을 의미합니다. Java 프레임워크를 활용하기 위해 Java RMI.

SOAP와 이러한 기술의 주요 차이점은 다음과 같습니다.

1. HTTP를 통한 작업 – 모든 RPC 기술에는 하나의 큰 한계가 있는데, 그것은 HTTP 프로토콜로 작동하지 않는다는 것입니다. 웹의 모든 애플리케이션은 이 프로토콜로 작동해야 했기 때문에, 이는 RPC 스타일 웹 서비스에 액세스해야 하는 클라이언트에게 큰 장애물이었습니다.
2. 비표준 포트 작업 – RPC 스타일 웹 서비스는 HTTP 프로토콜에서 작동하지 않았기 때문에 클라이언트가 이러한 웹 서비스의 기능에 액세스할 수 있도록 별도의 포트를 열어야 했습니다.