웹 서비스를 SOAP 또는 REST 서비스로 노출시킬 때 결정하는 요소는 무엇입니까?


30

내가 아는 한 SOAP 소비에는 SOAP 스택이 필요하므로 클라이언트가 소비하기가 더 어렵습니다. 즉, POST 데이터와 헤더의 형식을 올바르게 지정한 다음 SOAP 스택을 제공해야합니다. REST를 사용하면 쿼리 문자열의 인수로 HTTP GET 요청을하고 XML이라고 생각되는 텍스트를 다시 얻을 수 있습니다.

SOAP의 추가 오버 헤드 / 복잡성은 무엇을 언제, 언제, 언제, 무엇을 할 수 있을까요?

답변:


17

이전에 REST API를 구현했으며 실제로 좋아했습니다. 일반적으로 REST over SOAP 를 구현할 때 클라이언트 / 서버는보다 직교적인 의미이므로 클라이언트에 영향을주지 않고 서버를 훨씬 더 자유롭게 변경할 수 있습니다. 이 직교성은 HTTP 동사를 통해보다 추상적이고 이미 정의 된 통신을 사용하기 때문입니다. 또한 REST 응답에 포함 된 하이퍼 링크를 사용하면 API를 비교적 쉽게 확장하고 확장 할 수 있습니다. 고객은 이러한 내장 된 링크를 따라 인간이 웹 페이지의 링크를 따라 더 많은 정보를 얻기 위해 '드릴 다운'하는 것처럼 새로운 리소스에 접근해야합니다.

그 말로, 나는 SOAP을 사용해야한다고 들었던 동료가 있었고 항상 그것에 대해 불평했습니다. 그래서 두 가지에 대해 좀 더 자세히 조사했습니다.

일반적으로 내가 찾은 것은 수백, 수천 또는 수백만의 클라이언트 가있을 때 REST가 고도로 분산 된 애플리케이션에 적합 하다는 것입니다 . 한 가지 이유는 위에서 언급 한 직교성이고, 다른 이유는 HTTP를 사용하므로 무료로 제공되는 캐싱입니다.

SOAP는 클라이언트를 위해 더 작은 API가 필요할 때 더 빨리 갈 수있는 방법 일 수 있으며 확장성에 대해 너무 걱정하지 않아도됩니다. 리소스를 중심으로 구조화 된 아키텍처가없는 경우 REST를 구현할 수 있도록 앱을 재구성하는 데 시간이 걸리기 때문에 더 적합 할 수도 있습니다.


2
HTTP가 아닌 리소스 패러다임과 상태 부족으로 인해 캐싱이 발생합니다.
dietbuddha

@dietbuddha HTTP는 무료로 구현을 제공합니다.
Jacob Raihle

17

사소한 것일 수도 있지만 REST는 전적으로 HTTP를 기반으로합니다.

SOAP에는 HTTP가 필요하지 않으며 원하는 전송을 자유롭게 사용할 수 있습니다.

SOAP 메시지는 비동기식으로 안정적으로 라우팅 될 수 있지만 REST는 거의 동기식 패러다임입니다.

REST는 보내고받는 데이터의 모양에 대해 아무 것도 알려주지 않습니다. WADL이 있지만 대부분 API의 문서화에 의존합니다. SOAP에는 데이터 기술에 오류가 덜 발생하도록 XML 기술 서커스가 있습니다. WSDL, 스키마 ...

하루가 끝나면 REST는 기본적으로 HTTP 기반의 파일 시스템을 제공합니다. 시스템이 해당 패러다임에 맞을 수 있다면 좋은 선택 일 것입니다.


여러 전송에 대해 +1 SMTP와 같은 작업을 지원하는 전송에 독립적 인 프로토콜이 실제로 필요한 경우 REST가 종료됩니다. 그러나 일반적으로 HTTP는 충분하지만 ...
sleske

6
REST가 HTTP에 어떻게 연결되어 있는지 보지 못합니까? 구현 세부 사항입니다. 대부분의 REST 구현은 HTTP를 사용하지만 FTP와 같은 다른 프로토콜을 통해 REST를 구현할 수없는 이유는 알 수 없습니다.
edalorzo

REST는 특정 프로토콜 심판에 통신을 제한하지 않습니다 ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
NMTOKEN

7

SOAP의 추가 오버 헤드 / 복잡성은 무엇을 언제, 언제, 언제, 무엇을 할 수 있을까요?

이 둘의 가장 큰 차이점은 REST가 상태 비 저장 인 것으로 가정하고 SOAP는 그렇지 않다는 것 입니다. 실제로 많은 REST 구현은 실제로 OAuth와 같은 것을 통해 세션에서 일부 상태를 구현합니다.

또 다른 차이점은 REST는 매우 "자원"이거나 명사 지향 입니다. CRUD 작업을 통해 리소스와 상호 작용합니다. 이 패러다임에 맞지 않는 것은 번거롭고 어색합니다.

반면에 SOAP는 RPC (원격 프로 시저 호출) 프로토콜 입니다. 패러다임과 함께 제공되지 않고 전송 계층 일뿐입니다.


1
SOAP와 REST는 최종 결과를 얻는 수단 일뿐입니다. 작업에 적합하거나 적합하지 않을 수 있습니다. 따라서 REST도 전송 계층으로 볼 수 있습니다. State / less보기조차도 유지되지 않습니다. 다른 유형의 API와 다른 유형의 API로 모두 특징을 디자인 할 수 있습니다. SOAP 및 REST 엔드 포인트가 모두있는 이중 API를 사용할 수도 있습니다. 그리고 XML-RPC 엔드 포인트. 그리고 Apache Thrift 엔드 포인트. 그리고 Google 프로토콜 버퍼 엔드 포인트. 그리고 또 뭐. 하루가 끝나면 모든 것이 RPC 일뿐입니다.
JensG

4

REST는 post도 사용합니다. 실제로 REST를 사용할 때 http 동사는 어떤 작업이 진행되고 있는지 알려줍니다.

REST와 SOAP는 인터넷을 통해 데이터를 전달하는 표준과 다릅니다.

웹 서비스를 사용하는 사람들이 .net 및 Visual Studio를 사용하고 있다는 것을 알지 못하면 SOAP 대신 REST를 사용하는 것이 좋습니다. SOAP를 사용할 때 대부분의 작업을 수행하는 .net VS를 제외하고 REST 웹 서비스를 사용하는 것이 일반적으로 훨씬 쉽습니다.


4
Java에서도 SOAP 지원이 훌륭합니다.

4

내가 언급 할 한 가지는 상호 운용성입니다. .NET으로 작성된 응용 프로그램에서 서비스를 호출하고 서버가 Java (또는 다른 조합)로 작성된 경우 REST로 이동하십시오. SOAP 구현 사이에 약간의 비 호환성이 너무 많아서 더 이상 고려하지 않아도되었습니다.


2
동의하다. SOAP는 업계 표준이지만 지나치게 복잡하여 구현이 중단되거나 불완전합니다. 또한 SOAP는 다른 접근 방식에 비해 성능 및 트래픽 측면에서 가장 큰 공간을 차지합니다.
JensG

1

애플리케이션 요구 사항에 따라 SOAP 및 REST를 측정하는 데 도움이되는 단순하고 시각적 인 가이드가 필요한 경우 ...

Vijay Prasad Gupta는 간단하고 유용한 흐름도를 만들었습니다.

플로우 차트에 직접 링크 : https://drive.google.com/file/d/0B3zMtAq1Rf-sdVFNdThvNmZWRGc/edit

기사 링크 : https://www.linkedin.com/pulse/20140818062318-7933571-soap-vs-rest-flowchart-to-determine-the-right-web-services-protocol-for-your-needs


그것은 실제로 꽤 괜찮은 순서도입니다. 여기에 단일 답변이 REST를 통한 SOAP의 이점을 다루지 않는 것에 놀랐습니다. 그러나 그 순서도는 그렇지 않습니다. 플로우 차트를 링크 대신 이미지로 포함시킬 수 있다고 생각합니다.
jleach

-2

지금은 2015 년입니다. 지금 SOAP가 죽기를 바랐지만 여전히 나쁜 냄새처럼 남아 있습니다. 가장 기본적인 "예제"응용 프로그램 외에는 SOAP 서비스와의 통합에 어려움이 있습니다. 다중 구현의 여러 가지 단점과 미묘한 (비밀하지 않은) 비 호환성과 결합 된 여러 수준의 많은 옵션이있는 복잡한 아키텍처입니다. 나는 그것에 대해 좋은 경험을 한 번도 없었습니다. 반면에 REST는 산들 바람입니다. 모두가 HTTP를 이해합니다. 대부분의 경우 JSON에는 XML InfoSet보다 훨씬 많은 유틸리티가 있습니다.

SOAP의 복잡성에 대한 아이디어를 제공하려면 SOAP 라이브러리를 프로젝트에 통합하십시오. Java의 경우 가장 간단한 Apache Axis2 클라이언트 (간단한 ADB 데이터 바인딩 사용)는 23 개의 새로운 JAR을 가져옵니다. 이십 삼! 20MB의 라이브러리 팽창. CXF는 비슷합니다. 마지막으로 계산했을 때 21 JAR.

정말로 원한다면 간단한 HTTP 라이브러리로 REST를 수행 할 수 있습니다.


1
이것은 맹렬한 것처럼 읽습니다. 답변하는 방법
gnat

네가 옳아. 죄송합니다, 당시에 SOAP 스프로
씻어 냈습니다

1
우리는 90 년대 CORBA / IDL에 대해 동일한 불만을 제기했습니다. 그런 다음 갑자기 "간단한 개체 액세스 프로토콜".. 간단합니다! 멋지다! 빠를 것이다. 10 년 후, 너무 복잡한 것으로 간주됩니다. JSON (학생 실 설정 또는 제한된 "내가하는 일을 알고 있습니다"빠른 수정 상황에서 데이터 전송 작업을위한 실제 바퀴)과 RESTful ops가 함께 제공됩니다. 린스, 반복 ...
David Tonhofer

SOAP에 대한 모든 진실 된 진술은 rant로 읽어야합니다. 설계 상 엔터프라이즈 방식이며 데이터를 보내려는 수많은 옵션을 제공합니다. 내가 작업 한 몇 가지 SOAP 인터페이스와 관련하여, 각각은 매우 중복 된 엉망이었다 (정확히 SOAP의 결함은 아니지만 SOAP에 대한 친화 성은 bloatware에 대한 친화 성과 관련됨). 뛰게해서 미안해
maaartinus
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.