SOAP보다 REST를 선호하는 이유는 무엇입니까?

복잡한 객체를 앞뒤로 전달할 웹 서비스가 필요한 경우 SOAP over REST를 선호해야하는 이유가 있습니까?SOAP보다 REST를 선호하는 이유는 무엇입니까?

<soap:Envelope> 
    <soap:Header> 
    <Credentials> 
     <User>Joe</User> 
     <Password>abc123</Password> 
    </Credentials> 
    </soap:Header> 
    <soap:Body> 
    <MyComplexBusinessObject> 
     <Search> 
     <First>Joe</First> 
     <Last>Smith</Last> 
     </Search> 
     ... 
     ... 
    </MyComplexBusinessObject> 
    </soap:Body> 
</soap:Envelope>

REST를 사용하여, 나는 다음과 같은 XML을 게시하고 기본 인증을 사용하여 인증하도록 클라이언트를 요청하는 것입니다 :

이

<MyComplexBusinessObject> 
    <Search> 
    <First>Joe</First> 
    <Last>Smith</Last> 
    </Search> 
    ... 
    ... 
</MyComplexBusinessObject>

SOAP 메시지가 약간 더 여기 가능한 SOAP 메시지의 예입니다 복잡하지만,별로. 그것들은 여전히 XML이지만 SOAP에는 WSDL이 있으며 대부분의 프로그래밍 환경은 프록시 클래스를 생성합니다. 그러나 대부분의 사람들은 사용하기 쉽기 때문에 대신 REST를 사용해야한다고 말합니다. 하지만 SOAP를 사용하는 것이 더 힘들지는 않습니다.

이 나는 뭔가를 놓치고 있습니까?

출처

2010-11-24 Books

왜 XML *이 중요한지. JSON은 (프로그래밍의 관점에서 보면) 훨씬 깔끔하고 컴팩트합니다. '[{ '첫': '조', '마지막': '스미스'}, ...]' –

당신은 어떻게 복잡한 객체를 전달하겠습니까? 물론 JSON을 사용할 수는 있지만 REST 용 SOAP를 포기하는 것을 정당화하기에 충분하지 않습니다. 개체에 중첩 된 필드가있을 수 있으며 URL로 잘 변환되지 않을 수 있습니다. – Books

실제로,이 경우, 더 나은 일치는 표준 POST 변수로'/ search'에 게시됩니다. '1 = Joe, Smith & 2 = John, Citizen & ... '예를 들면. 검색 이외의 다른 검색을 원한다면 SOAP은 한 URL에서 모든 것을 취할 수 있지만 REST는 그렇지 않습니다 (한 줄에 하나의 URL이 있습니다.)/검색을 할 수만 있다면/joe + smith' 또는 그보다 더 좋을 것 같은). –

"복잡한 개체를 앞뒤로 통과"하는 첫 번째 요구 사항은 구조가 REST의 많은 이점을 제거하도록 제한합니다. SOAP은 원격 객체에 액세스하도록 설계되었으므로 REST는 그렇지 않습니다. REST는 text/plain과 같은 단순한 미디어 유형 전달을 지원합니다.이 유형은 객체를 처리하는 것보다 훨씬 원시적입니다.

아직 보지 않았다면 this 질문과 그 답변은 대부분 REST와 SOAP 문제를 다룹니다.

출처

2010-11-24 14:13:21

대부분의 RESTful 서비스는 "REpresentational State Transfer"라고하는 복잡한 객체를 앞뒤로 전달하는 것으로 설명 될 수 있습니다. 거의 아무도'text/plain'을 사용하지 않습니다. REST는 문서 지향적이며 SOAP은 RPC와 유사한 솔루션입니다. – jfs

@ J.F.Sebastian RESTful이라고 주장하는 대부분의 서비스는 실제로 존재하지 않습니다. 클라이언트와 서버간에 객체를 전달하면 메시지에서 명시 적으로 선언되지 않은 특정 의미와 함께 유형을 공유하게됩니다. 이는 REST의 제약 조건을 위반합니다. –

REST의 주요 장점 중 하나는 브라우저와 HTTP 스택을 호출하고 사용해야한다는 것입니다. 거의 모든 장치와 컴퓨터에 해당 기능이 있습니다. 따라서 사용의 용이성과 도달 범위가 주요 목표라면 REST를 사용하십시오.

SOAP의 주요 이점 중 하나는 WSDL 서비스 설명이 있고 서비스를 자동으로 발견하고 해당 서비스 설명에서 유용한 클라이언트 프록시를 생성 할 수 있다는 것입니다 (서비스 호출, 방법 등).

검색 가능성과 엄격한 공식적인 서비스 설명이 더 중요 할 경우 SOAP를 사용하십시오 (서비스를 호출하기 위해서는 완전한 SOAP 클라이언트가 필요하다는 단점이 있습니다 - 웹 브라우저가 충분하지 않을 수 있습니다).

SOAP는 사용하기가 더 어렵지 않지만 사용 가능한 브라우저라는 측면에서 볼 때 상당히 널리 퍼지지는 않습니다. 모든 브라우저는 REST 서비스를 호출하고 응답을 얻을 수 있지만 그 응답을 구문 분석하고 해석해야합니다. SOAP은 멋진 데이터 구조를 갖지만 SOAP 클라이언트가 필요합니다.

출처

2010-11-24 12:06:50

하지만 진정으로 완전한 SOAP 클라이언트가 필요합니까? 메시지를 복사하고 공백을 채우고 끝점에 POST 할 수는 없습니까? 그게 REST 클라이언트와 거의 같을까요? 나는 내가 REST에 반대하는 것처럼 들리게하려고 노력하지 않고있다. 나는 확신하고 싶다. – Books

@marc_s, "하지만 그 구문을 해석하고 해당 응답을 해석해야합니다."JavaScript를 사용하여 COD를 사용하지 않으면이 문제를 해결할 수 있습니까? – Anders

@Ashley : SOAP 서비스와 이야기하고 싶다면, 내가 아는 한 SOAP 클라이언트가 필요합니다. 나는 당신이 그 URL에 "그냥 POST"할 수 있다고 생각하지 않는다. (어쨌든 나 자신을 시도한 적이 없다.) –

SOAP과 REST를 서로 다른 기능을 수행하도록 설계된 직교 API로 간주합니다.

SOAP은 기본적으로 멋진 RPC입니다. 따라서 계산 요청을 서버로 보내고 결과를 다시 얻으려면 SOAP를 사용하십시오. 로컬 일 경우 객체 인스턴스에 대한 메소드 호출입니다.

REST는 균일 한 API를 사용하여 POO가 아니라 원격 객체를 생성, 검색, 업데이트 및 삭제하는 방법입니다. 로컬 일 경우 파일로 작업하는 것과 같습니다.

그래서 그들은 실제로 다른 필요에 응답합니다. 당신은 다른 사람의 일을하기 위해 자살 할 수는 있지만 그 의미를 왜곡하십시오.

출처

2013-04-10 20:07:05 ddalex

서비스와 클라이언트를 모두 개발하면 SOAP을 사용하는 것이 REST만큼 쉽습니다 (실제로는 더 쉽습니다).

당신은 REST를 통해 경우 이러한 조건의 충족을 SOAP를 선호 할 수 있습니다 :

전체 서비스 API가 아니라 하나의 개체, 복잡하다.
이 서비스는 상대적으로 작은 네트워크 내에서 사용되고 성능은 중요한 요구 사항은 아닙니다.
서비스와 API 문서를 개발하는 데 최소한의 시간을 투자하기로 결정했습니다.

출처

2015-04-20 11:21:03 Huy

SOAP보다 REST를 선호하는 이유는 무엇입니까?

답변

관련 문제