웹서비스에 SOAP를 사용하는 이유는 무엇인가요?

웹 서비스를 구축할 때는 두 가지 방법을 사용할 수 있습니다:

• SOAP
• REST

대부분의 사람들은 저항이 적은 경로, 즉 REST를 선택합니다. 이는 단순성, 개발 용이성, HTTP의 원래 사용 방식대로 사용, 캐시 프록시 활용, 사람이 더 읽기 쉬운 결과 등을 의미합니다.

반면에 SOAP는 REST보다 더 무겁고 많은 [사양][1]으로 뒷받침됩니다. 그러나 더 복잡하기 때문에(SOAP는 예전에는 단순한 객체 액세스 프로토콜의 약어였습니다. 아닌 것으로 판명됨) SOAP는 많은 사람들이 좋아하지 않습니다.

**두 접근 방식 모두 효과가 있으며 장단점이 있습니다.

예를 들어, SOAP는 HTTP(S) 뿐만 아니라 모든 전송 프로토콜을 사용할 수 있고, 보안과 관련하여 더 많은 옵션을 제공하며, 안정적인 메시징 등을 제공합니다. 반면에 REST는 다양한 유형의 데이터 형식을 허용하고, JSON 형식으로 인해 브라우저를 더 잘 지원하며, REST의 성능이 더 우수하다는 등의 장점이 있습니다.

웹에서 SOAP과 REST를 비교하는 많은 자료를 찾을 수 있으므로 더 자세히 설명하지 않겠습니다. 제가 강조하고 싶은 것은 어떤 경우에는 한 쪽이 다른 쪽보다 더 잘 작동하며 특정 사례를 고려하여 어떤 것을 구현할지 결정하고 선택하는 것은 사용자의 몫이라는 사실입니다.

편집: 질문에 답하자면:

사용자 159088이 답변에서 언급 한 중요한 점은 [...][...] WSDL 파일에서 시작하여 매우 쉽게 클라이언트를 생성 할 수 있다는 것입니다 [...] &"!

이에 대해 더 자세히 설명하고 싶습니다:

표준화되어 있기 때문에 표준(WSDL)을 아는 사람은 웹서비스가 어떤 작업을 제공하고 데이터가 어떻게 교환되는지 알 수 있다는 의미로 표준화된 WSDL과 함께 SOAP을 사용할 수 있습니다.

이러한 지식은 예를 들어 WSDL 파일에서 유형 안전 바인더 클래스/객체를 생성하는 도구를 만드는 데 사용할 수 있습니다. 교환되는 데이터의 요청과 인코딩/파싱을 수동으로 구현하지 않고도 생성된 클래스를 사용하여 (RPC를 만드는 데) 사용할 수 있습니다.

반면, REST의 경우 교환되는 데이터의 모양에 대한 표준(예: WSDL 스키마)이 없습니다. 따라서 데이터를 직접 파싱해야 하는 경우가 많습니다.

두 번째 요점은 REST가 주로 HTTP(s) 프로토콜에서 작동한다는 점입니다(이를 기반으로 합니다). HTTP(s) 프로토콜의 CRUD 동사(CREATE/READ/UPDATE/DELETE)를 사용합니다. SOAP는 이 프로토콜에 의존하지 않으므로 다른 프로토콜과도 함께 사용할 수 있습니다.