웹 서비스를 위한 SOAP 또는 REST?
REST가 웹 서비스를 하는 데 더 나은 접근방식입니까 아니면 SOAP입니까?아니면 서로 다른 문제에 대해 서로 다른 도구입니까?아니면 미묘한 문제인가요? 즉, 어떤 분야에서는 다른 분야보다 약간 나은가요?
저는 특히 그러한 개념들과 PHP-유니버스 그리고 현대의 고급 웹 애플리케이션과의 관련성에 대한 정보를 주시면 감사하겠습니다.
저는 휴렛패커드에서 근무할 때 코드 생성 및 WSDL 생성을 포함한 최초의 SOAP 서버 중 하나를 개발 중이던 원래 사양에서 구축했습니다.저는 비누를 어떤 것에도 사용하는 것을 추천하지 않습니다.
SOAP라는 약자는 거짓말입니다.단순하지도 않고 객체 지향적이지도 않으며 액세스 규칙을 정의하지도 않습니다.그것은, 거의 틀림없이, 의정서입니다.그것은 돈 박스의 사상 최악의 스펙이며, 그가 "COM"을 실행한 사람이기 때문에, 그것은 꽤 대단한 업적입니다.
SOAP에는 전송을 위한 REST와 데이터 표현을 위한 JSON, XML 또는 평문으로 수행할 수 없는 유용한 작업이 없습니다.운송 보안을 위해 https를 사용할 수 있습니다.인증의 경우 기본 인증입니다.세션 때는 쿠키가 있습니다.REST 버전은 더 단순하고, 더 선명하며, 더 빨리 실행되며, 대역폭을 덜 사용하게 됩니다.
XML-RPC는 요청, 응답 및 오류 프로토콜을 명확하게 정의하며 대부분의 언어에 적합한 라이브러리가 있습니다.그러나 XML은 많은 작업에 필요한 것보다 더 무겁습니다.
REST는 아키텍처이고 SOAP는 프로토콜입니다.
그것이 첫번째 문제입니다.
REST 애플리케이션으로 비누 봉투를 보낼 수 있습니다.
SOAP 자체는 사실 꽤 기본적이고 간단합니다. 그 위에 WSS-* 표준이 있어서 매우 복잡합니다.
사용자가 다른 애플리케이션 및 기타 서버라면 현재 SOAP 프로토콜을 많이 지원하고 있으며, 데이터 이동의 기본은 기본적으로 현대 IDE에서 마우스 클릭입니다.
사용자가 RIA 또는 Ajax 클라이언트일 가능성이 높다면 SOAP보다 단순하고 클라이언트(특히 JSON)에 더 기본적인 것을 원할 것입니다.
HTTP를 통해 전송되는 JSON 패킷은 REST 아키텍처가 아니라 URL에 대한 메시지일 뿐입니다.모든 것이 완벽하게 작동하지만 REST 관용구에 핵심적인 요소가 있습니다.하지만 그 둘을 혼동하기 쉽습니다.그러나 HTTP 요청을 말하는 것이라고 해서 REST 아키텍처가 반드시 있는 것은 아닙니다.HTTP가 전혀 없는 REST 응용 프로그램을 사용할 수 있습니다(심지어, 이것은 드문 일입니다.
따라서 SOAP에 대해 "편안한" 서버와 소비자가 있다면 SOAP 및 WSS 스택을 잘 이용할 수 있습니다.좀 더 임시방편적인 일들을 하고 있고 웹 브라우저와의 더 나은 인터페이스를 원한다면 HTTP를 통한 가벼운 프로토콜도 잘 작동할 수 있습니다.
REST는 SOAP와는 근본적으로 다른 패러다임입니다.REST에 대한 좋은 자료는 여기에서 찾을 수 있습니다.내 아내에게 REST를 어떻게 설명했는지.
읽을 시간이 없다면, 여기 짧은 버전이 있습니다: REST는 "명사"에 초점을 맞추고, 그 명사들에 적용할 수 있는 "동사"의 수를 제한함으로써 약간의 패러다임의 변화입니다.허용되는 동사는 "get", "put", "post" 및 "delete"뿐입니다.이것은 많은 다른 동사들이 많은 다른 명사들에 적용될 수 있는 SOAP와 다릅니다.
REST의 경우 4개의 동사가 해당 HTTP 요청에 매핑되는 반면 명사는 URL로 식별됩니다.따라서 서버의 상태와 클라이언트의 상태가 불분명한 경우가 많은 SOAP보다 상태 관리가 훨씬 투명해집니다.
실제로는 이 중 대부분이 사라지지만 REST는 일반적으로 JSON으로 결과를 반환하는 단순한 HTTP 요청을 언급하는 반면 SOAP는 XML을 전달하여 통신하는 더 복잡한 API입니다.두 가지 모두 장단점이 있지만, SOAP의 모든 기능이 필요한 경우는 거의 없기 때문에 경험상 REST가 더 나은 선택임을 알게 되었습니다.
2012년 질문에 대한 간략한 설명:
REST가 매우 효과적인 분야는 다음과 같습니다.
제한된 대역폭 및 리소스.반환 구조는 실제로 어떤 형식으로든 적용된다는 것을 기억하십시오(개발자 정의).또한 REST 방식은 표준 GET, PUT, POST, DELETE 동사를 사용하기 때문에 어떤 브라우저도 사용할 수 있습니다.REST는 현재 대부분의 최신 브라우저에서 지원하는 XMLHtpRequest 개체도 사용할 수 있으며, 이 개체는 AJAX의 추가 보너스를 추가합니다.
완전히 상태 비저장 작업입니다. 작업을 계속해야 하는 경우 REST가 최선의 방법이 아니며 SOAP가 더 적합할 수 있습니다.그러나 상태 비저장 CRUD(Create, Read, Update 및 Delete) 작업이 필요한 경우 REST가 해당됩니다.
캐싱 상황. REST 방식의 완전한 상태 비저장 동작으로 인해 정보를 캐싱할 수 있다면 완벽합니다.이는 위의 세 가지 솔루션에서 많은 부분을 다룹니다.
그럼 왜 SOAP까지 고려해야 하죠?SOAP는 상당히 성숙하고 명확하며 완벽한 사양을 갖추고 있습니다.REST 접근 방식은 접근 방식이며 개발에 광범위하게 개방되어 있으므로 다음과 같은 사항이 있다면 SOAP를 사용하는 것이 좋습니다.
비동기식 처리 및 호출. 응용 프로그램에 안정성과 보안 수준이 필요한 경우 SOAP 1.2는 이러한 유형의 작동을 보장하기 위한 추가 표준을 제공합니다.WSRM – WS-Reliable Messaging과 같은 것들입니다.
정식 계약. 양측(제공자와 소비자)이 교환 형식에 합의해야 하는 경우 SOAP 1.2는 이러한 유형의 상호 작용에 대한 엄격한 사양을 제공합니다.
상태가 좋은 작업.애플리케이션에 상황별 정보와 대화형 상태 관리가 필요한 경우 SOAP 1.2에는 WS* 구조에 보안, 트랜잭션, 조정 등을 지원하는 추가 사양이 포함되어 있습니다.비교적 REST 방식은 개발자가 이러한 맞춤형 배관을 구축할 수 있게 합니다.
http://www.infoq.com/articles/rest-soap-when-to-use-each
SOAP는 현재 주어진 WSDL에서 클라이언트를 생성할 뿐만 아니라 서비스 계층을 위한 많은 보일러 플레이트 코드를 생성할 수 있는 더 나은 도구의 이점을 가지고 있습니다.
REST는 보다 단순해지고, 그 결과 유지보수가 쉬워지고, 웹 아키텍처의 핵심에 위치하며, 프로토콜 가시성을 향상시킬 수 있으며, WWW 자체의 크기로 확장할 수 있는 것으로 입증되었습니다.Ruby on Rails와 같은 REST 서비스를 구축하는 데 도움이 되는 프레임워크도 있으며 ADO와 같은 클라이언트 작성에도 도움이 됩니다.NET 데이터 서비스.하지만 대부분의 경우 도구 지원이 부족합니다.
SOAP는 툴링의 관점에서 유용합니다. WSDL은 툴로 쉽게 소비되기 때문입니다.따라서 자신이 좋아하는 언어로 웹 서비스 클라이언트를 생성할 수 있습니다.
REST는 AJAX'y 웹 페이지와 잘 어울립니다.요청을 단순하게 유지하면 자바스크립트에서 직접 서비스 호출을 할 수 있으며, 이는 매우 편리합니다.응답 XML에 네임스페이스가 없는 것을 피하려고 노력합니다. 브라우저가 그것들을 차단하는 것을 본 적이 있습니다.따라서 xsi:type은 지나치게 복잡한 XML 스키마가 아니라 사용자에게 적합하지 않을 것입니다.
REST도 성능이 더 좋은 경향이 있습니다.REST 응답을 생성하는 코드의 CPU 요구사항은 SOAP 프레임워크가 보여주는 것보다 낮은 경향이 있습니다.또한 XML 생성 오리가 서버 측에 정렬되어 있으면 XML을 클라이언트로 효과적으로 스트리밍할 수 있습니다.데이터베이스 커서 행을 읽고 있다고 상상해 보십시오.행을 읽을 때 XML 요소로 형식을 지정하고 서비스 소비자에게 직접 입력합니다.이렇게 하면 XML 출력을 쓰기 시작하기 전에 메모리의 모든 데이터베이스 행을 수집할 필요가 없습니다. 읽기와 쓰기가 동시에 이루어집니다.새로운 템플릿 엔진이나 XSLT를 조사하여 REST를 위한 스트리밍을 실행할 수 있습니다.
반면 SOAP는 도구로 생성된 서비스가 큰 블록으로 생성된 후 작성되는 경향이 있습니다.이것이 절대적인 사실은 아닙니다. 첨부 파일을 사용하는 것처럼 SOAP에서 스트리밍 특성을 얻을 수 있는 방법이 있습니다.
제 의사 결정 과정은 다음과 같습니다. 만약 제가 서비스를 소비자들이 쉽게 이용하기를 원하며, 제가 작성하는 메시지가 중간에서 작은 크기(10MB 이하)이고, 서버에서 CPU 사이클을 추가로 태우는 것도 상관없다면 SOAP를 사용합니다.웹 브라우저에서 AJAX에 서비스를 제공해야 하거나 스트리밍이 필요하거나 응답이 방대하면 REST를 수행합니다.
마지막으로, WS-Security 및 상태 저장 웹 서비스 제공과 같은 SOAP를 중심으로 구축된 많은 우수한 표준이 있으며, 이는 적합한 도구를 사용하는 경우에 연결할 수 있습니다.그런 종류의 것들은 정말로 차이를 만들고, 당신이 털이 많은 요구사항들을 만족시키는 데 도움을 줄 수 있습니다.
이것이 오래된 질문이라는 것을 알지만 저는 제 대답을 게시해야 합니다. 아마도 누군가가 그것이 유용하다고 생각할 것입니다.비누보다 REST를 추천하는 사람이 얼마나 많은지 믿을 수가 없습니다.저는 이 사람들이 개발자가 아니거나 실제로 REST 서비스를 합리적인 규모로 구현해 본 적이 없다고 추측할 수밖에 없습니다.REST 서비스를 구현하는 것은 SOAP 서비스를 구현하는 것보다 훨씬 오래 걸립니다.그리고 결국에는 더 엉망이 되기도 합니다.SOAP를 99% 선택하는 이유는 다음과 같습니다.
1) REST 서비스를 구현하는 것은 SOAP 서비스를 구현하는 것보다 무한히 오래 걸립니다.모든 현대 언어/프레임워크/플랫폼이 WSDL에서 읽고 프록시 클래스와 클라이언트를 출력할 수 있도록 도구가 존재합니다.REST 서비스를 구현하는 작업은 수작업으로 수행되며 - 문서를 읽음으로써 이를 얻습니다.또한, 이 두 가지 서비스를 구현하는 동안 실제 스키마나 참조 문서가 없기 때문에 파이프를 가로질러 무엇이 돌아올지 "추측"해야 합니다.
2) 어쨌든 XML을 반환하는 REST 서비스를 쓰는 이유는 무엇입니까?REST를 사용하면 각 요소/속성이 나타내는 유형을 알 수 없다는 것이 유일한 차이점입니다. 이를 구현하고 언젠가 항상 인트라고 생각했던 필드에 문자열이 나타나지 않기를 바랍니다.SOAP는 WSDL을 사용하여 데이터 구조를 정의하므로 쉬운 작업입니다.
3) 비누를 사용하면 비누 봉투의 "윗머리"가 있다는 불만을 들었습니다.요즘 시대에 우리는 정말로 몇 바이트도 걱정해야 합니까?
4) REST를 사용하면 브라우저에 URL을 넣고 데이터를 볼 수 있다는 주장을 들었습니다.네, REST 서비스에서 간편 인증을 사용하거나 인증을 사용하지 않는 경우.예를 들어, 넷플릭스 서비스는 요청을 제출하기 전에 서명하고 암호화해야 하는 OAuth를 사용합니다.
5) 각 리소스에 대해 "읽을 수 있는" URL이 필요한 이유는 무엇입니까?만약 우리가 서비스를 구현하기 위해 도구를 사용하고 있다면, 실제 URL에 관심이 있습니까?
내가 계속해야 합니까?
제가 쓰는 대부분의 애플리케이션은 서버측 C#이나 자바, 또는 WinForms나 WPF의 데스크톱 애플리케이션입니다.이러한 애플리케이션은 REST가 제공할 수 있는 것보다 더 풍부한 서비스 API를 필요로 하는 경향이 있습니다.또한 웹 서비스 클라이언트를 만드는 데 몇 분 이상을 소비하고 싶지 않습니다.WSDL 프로세싱 클라이언트 생성 도구를 사용하면 클라이언트를 구현하고 비즈니스 가치를 높이는 작업으로 전환할 수 있습니다.
자, 만약 제가 일부 자바스크립트 아약스 호출을 위해 웹 서비스를 명시적으로 쓴다면, 클라이언트 기술을 알고 JSON을 활용하기 위해 REST에 있을 것입니다.제 생각에는 자바스크립트에서 사용하는 웹 서비스 API가 서버 쪽에서 더 잘 처리되는 것 같기 때문에 그다지 복잡하지는 않을 것 같습니다.
그런데 자바스크립트용 SOAP 클라이언트가 몇 개 있는데, jQuery가 하나 있다는 것을 알고 있습니다.따라서 SOAP는 JSON 문자열을 반환하는 REST 서비스만큼 훌륭하지 않고 자바스크립트에서 활용할 수 있습니다.따라서 임의의 수의 클라이언트 기술과 용도에 대해 유연할 수 있을 정도로 충분히 복잡해지고 싶은 웹 서비스가 있다면 SOAP를 사용할 것입니다.
먼저 REST를 사용하는 것이 좋습니다. Java를 사용하는 경우 JAX-RS와 Jersey 구현을 살펴보십시오.REST는 훨씬 단순하고 여러 언어로 인터럽팅하기 쉽습니다.
이 스레드에서 다른 사람들이 말했듯이 SOAP의 문제는 다른 WS-* 사양이 들어올 때 복잡성이 발생하고 WSDL, XSDs, SOAP, WS-Addressing 등의 잘못된 부분으로 빠져들면 수많은 인터럽트 문제가 발생한다는 것입니다.
REST v SOAP 논쟁을 판단하는 가장 좋은 방법은 인터넷을 보는 것입니다. 웹 공간, 구글, 아마존, 이베이, 트위터 등의 거의 모든 대형 업체들은 SOAP보다 RESTful API를 사용하고 선호하는 경향이 있습니다.
REST를 사용할 수 있는 또 다른 좋은 방법은 웹 애플리케이션과 REST 프론트엔드 사이에서 많은 코드와 인프라를 재사용할 수 있다는 것입니다. 예를 들어 리소스의 HTML 대 XML 대 JSON 렌더링은 JAX-RS 및 암시적 보기와 같은 프레임워크에서 일반적으로 꽤 쉽습니다. 또한 웹 브라우저를 사용하여 RESTful 리소스를 쉽게 사용할 수 있습니다.
저는 돈 박스가 SOAP를 농담으로 만들었을 것이라고 확신합니다 - '당신은 웹을 통해 RPC 메소드를 부를 수 있습니다'. 그리고 오늘 그는 그것이 웹 표준의 비대한 악몽이 된 것을 깨닫고 신음합니다 :-)
REST는 모든 곳에 빠르고 간편하게 구현됩니다(따라서 표준보다 '표준'에 가깝습니다).REST를 사용합니다.
저는 둘 다 각자의 자리가 있다고 생각합니다.제 의견으로는:
SOAP: 기존/중요 시스템과 웹/웹 서비스 시스템 간의 통합을 위해 WS-*가 적합한 기반 계층(보안, 정책 등)을 선택하는 것이 좋습니다.
RESTful: 최상위 계층(VIEW, 즉 javascripts가 URI로 호출을 받는 것)에서 공개 API와 웹 사이트 간의 통합을 위해 더 나은 선택.
언급되지 않은 한 가지는 SOAP 봉투에 신체 부위뿐만 아니라 헤더가 포함될 수 있다는 것입니다.이렇게 하면 XML의 완전한 표현력을 사용하여 대역외 정보를 주고 받을 수 있습니다.REST는 HTTP 헤더와 결과 코드로 제한하는 것으로 알고 있습니다.
(otoh, REST 서비스가 적용된 쿠키를 이용하여 "헤더" 타입의 대역외 데이터를 전송할 수 있습니까?)
XML-RPC를 간과하지 마십시오.가벼운 솔루션을 추구하는 경우, 몇 페이지의 텍스트로 정의하고 최소한의 코드로 구현할 수 있는 프로토콜에 대해 많은 이야기가 있습니다.XML-RPC는 수년간 존재해 왔지만 한동안 유행을 타지 않았습니다. 하지만 미니멀리즘의 매력이 최근에 부활한 것 같습니다.
2012년 업데이트된 질문(2차 현상금)에 답하고 오늘의 결과(기타 답변)를 검토합니다.
SOAP, 장단점
SOAP 1.2에 대해서 "REST"와 비교했을 때 장점과 단점...2007년부터 WSDL로 REST 웹 서비스를 설명할 수 있습니다. SOAP 프로토콜을 사용하면...즉, 조금만 더 열심히 하면 웹 서비스 프로토콜 스택의 모든 W3C 표준이 REST가 될 수 있습니다!
철학적이고 방법론적인 모든 논의를 일시적으로 피하는 시나리오를 상상할 수 있기 때문에 좋은 출발점이 됩니다.기술적으로는 유사한 서비스에서 "SOAP-REST"와 "NON-SOAP-REST"를 비교할 수 있고,
SOAP-REST(="REST-SOAP"): L과 같습니다.Mandel, WSDL2는 REST 웹 서비스를 설명할 수 있으며, 예시된 XML이 SOAP에 포섭될 수 있다고 가정하면, 모든 구현은 "SOAP-REST"가 될 것입니다.
비SOAP-REST: SOAP가 될 수 없는 모든 REST 웹 서비스...즉, 잘 알려진 REST 사례의 "90%"입니다.XML을 사용하지 않는 경우도 있고, SOAP 헤더나 규칙이 없는 다른 XML 구조를 사용하는 경우도 있습니다.PS: 비공식성을 피하기 위해 비교에서 REST 레벨 2를 가정할 수 있습니다.
물론, 좀 더 개념적으로 비교하기 위해, 모델링 방식이 다르기 때문에 "NON-REST-SOAP"과 "NON-SOAP-REST"를 비교해 보십시오.웹 서비스의 분류 체계를 완성하는 것은 다음과 같습니다.
비 REST-SOAP: REST가 불가능한 SOAP 웹 서비스...즉, 잘 알려진 SOAP 사례의 "90%"입니다.
NON-REST-NETH-SOAP: 네, "웹 서비스 모델링"의 세계는 다른 것들(예: XML-RPC)로 구성됩니다.
나머지 조건의 SOAP
비교 대상: SOAP-REST와 NON-SOAP-REST를 비교합니다.
프로스
몇 가지 용어를 설명해 드리자면,
계약상 안정성: 모든 종류의 계약('서면약정'으로 함)에 대하여,
견고성: SOAP 구조와 헤더의 안전성.메타데이터 통신(XML의 완전한 표현성을 갖춘)과 검증을 통해 변경이나 노이즈에 대해 "보험 정책"을 수립할 수 있습니다.
SOAP는 "거래 신뢰성(...)이 통신 장애에 대처합니다.SOAP는 재시도 로직에 대한 더 많은 제어 기능을 가지고 있으므로 더 많은 엔드 투 엔드 신뢰성과 서비스 보증을 제공할 수 있습니다."라고 E. Terman은 말합니다.
인기도에 따라 프로를 분류하면,
더 나은 도구(~70표):SOAP는 잘 정의되고 널리 받아들여지는 표준이기 때문에 2007년 이후로 그리고 여전히 2012년 이후로 더 나은 도구의 장점을 가지고 있습니다.@MarkCidade(27표), @DaveWoldrich(20표), @JoshM(13표), @TravisHesseman(9표) 참조.
표준 준수(25표): 저, @DaveWoldrich(20표), @cynicalman(5표), @Exitos(0표)가 전에 말했듯이 표준이 필요한 상황에서 비누가 필요합니다.
강건성: SOAP 헤더의 보험, @JohnSaunders (8표)
콘스
SOAP 구조는 더 복잡합니다(300표 이상). 여기에 있는 모든 답변과 "SOAP 대 REST"에 대한 출처는 SOAP의 중복성과 복잡성에 대해 어느 정도 비호감을 표시합니다.이는 공식적인 검증(아래 참조)과 견고성(위 참조)을 위한 요구사항의 자연스러운 결과입니다."REST NON-SOAP"(및 SOAP originator인 XML-RPC)은 보다 단순하고 비공식적일 수 있습니다.
작은 서비스를 사용할 때 "유일 XML" 제한은 성능에 장애가 됩니다(~50표). json.org/xml 및 이 질문 또는 기타 질문을 참조하십시오.이 점은 @toluju(41) 등이 보여주고 있습니다.
PS: JSON은 IETF 표준이 아니지만 웹 소프트웨어 커뮤니티에 대한 사실상의 표준을 고려할 수 있습니다.
SOAP로 서비스 모델링
이제 NON-SOAP-REST 비교를 통해 SOAP-NON-REST를 추가하고 SOAP을 사용하는 것이 더 나은 시기를 설명할 수 있습니다.
표준과 안정적인 계약의 필요성 ("PROS" 섹션 참조).추신: @saille에서 설명하는 전형적인 "표준에 대한 B2B 요구"를 참조하십시오.
공구가 필요합니다("PROS" 섹션 참조).PS: 표준 및 공식 검증 여부(아래 참조)는 공구 자동화에 중요한 문제입니다.
병렬 처리(아래의 "Context/Foundation" 섹션 참조): 더 큰 프로세스 및/또는 더 느린 프로세스, SOAP의 복잡성에 상관없이 신뢰성과 안정성이 최상의 투자입니다.
더 많은 보안이 필요합니다. HTTPS 이상이 필요하고 보호를 위해 추가 기능이 필요한 경우 SOAP가 더 나은 선택입니다(@Bell, 32표 참조)."요청/응답보다 복잡한 경로 또는 HTTP를 수반하지 않는 전송을 통해 메시지를 보내는 것", S. Seely. XML은 XML 암호화, XML 서명 및 XML 표준화를 제공하는 핵심 문제이며, SOAP를 사용해야만 WS-Security라는 잘 인정된 표준에 의해 이러한 메커니즘을 메시지에 포함시킬 수 있습니다.
더 많은 유연성 필요(제한 완화):SOAP는 URI와 정확하게 일치할 필요가 없으며 HTTP로 제한할 필요가 없으며 4개의 동사로 제한할 필요가 없습니다.@TravisHeseman(9표)의 말처럼 "임의 수의 클라이언트 기술과 용도에 맞게 유연한" 것을 원한다면 SOAP를 사용하십시오.
PS: XML은 JSON(외)보다 더 보편적/표현적이라는 것을 기억하세요.공식 검증 필요: W3C 스택은 공식적인 방법을 사용하며 REST는 더 비공식적이라는 것을 이해하는 것이 중요합니다.WSDL(공식 언어) 서비스 설명은 웹 서비스 인터페이스의 공식 사양이며 SOAP는 가능한 모든 WSDL 처방을 수용하는 강력한 프로토콜입니다.
맥락
히스토리
추세를 평가하는 것은 역사적 관점이 필요합니다.이 주제에 관해서는 10년 또는 15년의 관점...
W3C 표준화 이전에는 무정부 상태가 조금 있습니다.서로 다른 프레임워크로 상호 운용 가능한 서비스를 구현하는 것이 어려웠고, 기업 간에 상호 운용 가능한 것을 구현하는 것이 더 어렵고 비용이 많이 들며 시간이 많이 소요되었습니다.W3C 스택 표준은 복잡한 웹 서비스 세트의 상호 운용을 위한 라이트, 북쪽이었습니다.
AJAX를 구현하는 것과 같은 일상적인 작업의 경우 SOAP가 과중합니다.그래서, 간단한 접근법의 필요성은 새로운 이론 체계를 선택할 필요가 있습니다.그리고 구글, 아마존, 야후 등과 같은 대형 "웹 소프트웨어 플레이어"들이 최고의 대안, 즉 REST 접근법을 선택했습니다.이러한 맥락에서 REST 개념은 "경쟁 프레임워크"로서 도달되었으며, 오늘날(2012년) 이 대안은 프로그래머를 위한 사실상의 표준입니다.
기초
병렬 컴퓨팅(Parallel Computing)의 맥락에서 웹 서비스는 병렬 하위 작업을 제공하며 SOAP와 같은 프로토콜은 동기화 및 통신을 잘 보장합니다.작업 없음: 웹 서비스는 다음과 같이 분류될 수 있습니다.
거칠고 난감한 평행선
과제가 커질수록 "복잡성 논쟁"은 덜 중요해지고, 의사소통의 견고성과 계약의 견고성과 관련성이 높아집니다.
미묘합니다.
계약, WSDL 및 SOAP 표준과 관련된 "검증" 계층 때문에 다른 시스템이 서비스와 연동되어야 한다면 많은 고객들이 SOAP에 만족할 것입니다.
시스템에 호출하는 일상적인 시스템의 경우, 간단한 HTML 호출이 가능할 때 SOAP는 불필요한 오버헤드가 많이 발생한다고 생각합니다.
저도 같은 생각을 하고 있는데, 문제가 있을 때마다 다른 도구라고 생각합니다.
SOAP(Simple Object Access Protocol) 표준은 메시지 아키텍처 및 메시지 형식을 정의하는 XML 언어로, 작업에 대한 설명을 포함하는 웹 서비스에서 사용됩니다.WSDL은 웹 서비스와 액세스 방법을 설명하기 위한 XML 기반 언어로 SMTP, HTTP, FTP 등에서 실행됩니다.WSDL+XSD와 같은 서비스를 정의하려면 미들웨어 지원, 잘 정의된 메커니즘이 필요합니다. WS-Policy SOAP는 XML 기반 데이터를 반환합니다. SOAP는 보안 및 신뢰성에 대한 표준을 제공합니다.
RESTFUL(Representational State Transfer) 웹 서비스.그들은 2세대 웹 서비스입니다.RESTful 웹 서비스, SOAP 기반 서비스보다 HTTP를 통해 통신하며 XML 메시지나 WSDL 서비스-API 정의를 필요로 하지 않습니다.REST의 경우 미들웨어가 필요하지 않으며 HTTP 지원만 필요합니다.WADL Standard, REST는 XML, 평문, JSON, HTML 등을 반환할 수 있습니다.
많은 유형의 클라이언트가 RESTful 웹 서비스를 보다 쉽게 사용할 수 있는 동시에 서버 측이 진화하고 확장할 수 있도록 지원합니다.고객은 서비스의 일부 또는 모든 측면을 소비하고 다른 웹 기반 서비스와 매시업할 수 있습니다.
- REST는 표준 HTTP를 사용하므로 클라이언트를 생성하고 API를 개발하는 것이 더 간단합니다.
- REST는 XML, 평문, JSON, HTML과 같은 다양한 데이터 형식을 허용하지만 SOAP는 XML만 허용합니다.
- REST는 성능과 확장성이 더 뛰어납니다.
- 휴지 및 캐시 가능, SOAP 불가
- SOAP에 오류 처리가 없는 기본 제공 오류 처리
- REST는 특히 PDA 및 기타 모바일 장치에 유용합니다.
REST is 서비스는 기존 웹사이트와 통합하기 쉽습니다.
SOAP에는 프로토콜 세트가 있습니다. 이 프로토콜은 보안 및 신뢰성에 대한 표준을 제공하고 다른 WS 호환 클라이언트 및 서버와 상호 운용됩니다.SOAP 웹 서비스(예: JAX-WS)는 비동기 처리 및 호출을 처리할 때 유용합니다.
Complex API의 SOAP가 더 유용할 것입니다.
REST는 로이 필딩(Roy Fielding)이 발명한 아키텍처로, 그의 논문인 Architectural Styles and Design of Network-based Software Architecture에서 기술되었습니다.로이는 또한 월드 와이드 웹을 통한 문서 전송을 정의하는 프로토콜인 HTTP의 주요 작성자이기도 합니다.HTTP는 RESTful 프로토콜입니다.개발자가 "REST 웹 서비스 사용"에 대해 말할 때 "HTTP 사용"이라고 말하는 것이 더 정확할 수 있습니다.
SOAP는 HTTP 요청/응답 내부에 터널링하는 XML 기반 프로토콜이므로 SOAP를 사용하더라도 REST를 사용하고 있습니다.SOAP가 기본 HTTP에 중요한 기능을 추가하는지 여부에 대해 논란이 있습니다.
웹 서비스를 작성하기 전에 HTTP를 공부하는 것을 추천합니다.사양에 이미 정의된 기능으로 요구사항을 구현할 수 있으므로 다른 프로토콜이 필요하지 않을 가능성이 높습니다.
저는 같은 문제를 보고 있습니다.실제로 REST는 빠르고 쉽고 가벼운 통화와 응답에 좋고 디버깅(브라우저에 URL을 펌핑하여 응답을 보는 것보다 더 나은 방법)에 좋은 것 같습니다.
그러나 REST가 떨어지는 것처럼 보이는 것은 표준이 아니라는 사실과 관련이 있습니다(비록 표준으로 구성되어 있지만).대부분의 프로그래밍 라이브러리는 SOAP 기반 서비스를 소비하는 데 필요한 클라이언트 코드를 자동으로 생성하기 위해 WSDL을 검사하는 방법을 가지고 있습니다.지금까지 REST 기반 웹 서비스를 소비하는 것은 가능한 호출에 맞추기 위해 인터페이스를 작성하는 보다 임시방편적인 접근 방식으로 보입니다.수동 http 요청 후 응답 구문 분석.이것 자체가 위험할 수 있습니다.
SOAP의 장점은 일단 WSDL이 발행되면, 기업은 WSDL을 변경할 것이라는 논리를 기반으로 구성할 수 있다는 것입니다.마술을 부릴 수 있는 공간이 없습니다.해당 WSDL에 대해 모든 요청의 유효성을 검사할 수 있습니다. 그러나 WSDL은 REST 서비스를 제대로 설명하지 않으므로 통신을 위한 인터페이스에 동의할 수 있는 정의된 방법이 없습니다.
비즈니스적인 관점에서 보면 이는 의사소통이 해석과 변화에 열려있는 것처럼 보이는데, 이는 좋지 않은 생각으로 보입니다.
이 스레드의 맨 위 '답변'은 SOAP가 Simple Object-oriented Access Protocol을 의미한다고 말하는 것 같지만, Wiki the O를 보면 Object-oriented가 아닌 Object-oriented를 의미합니다.그것들은 다른 것들입니다.
저는 이 게시물이 매우 오래된 것을 알고 있지만, 제가 발견한 것을 가지고 응답해야겠다고 생각했습니다.
좋은 질문이네요...나는 당신을 잘못 인도하고 싶지 않기 때문에 당신만큼 다른 사람들의 대답에 열려있습니다.저에게는 간접비와 API의 사용 용도가 중요합니다.저는 클라이언트 소프트웨어를 만들 때 웹 서비스를 사용하는 것을 선호하지만 SOAP의 무게를 좋아하지 않습니다. REST는 무게가 더 가볍다고 생각하지만 클라이언트 관점에서 작업하는 것을 거의 좋아하지 않습니다.
저는 다른 사람들이 어떻게 생각하는지 궁금합니다.
이 팟캐스트를 들어보세요.듣지 않고 답을 알고 싶다면 OK, REST.하지만 저는 정말 듣는 것을 추천합니다.
일반적인 규칙은 브라우저 웹 클라이언트가 서비스에 직접 연결되기를 원한다면 REST를 사용해야 한다는 것입니다.백엔드 서비스 간에 구조화된 데이터를 전달하려면 SOAP를 사용합니다.
SOAP는 때때로 설치하기에 큰 어려움이 될 수 있으며, 단순한 웹 클라이언트 및 서버 데이터 교환을 위해 과도한 작업을 수행하는 경우가 많습니다.불행하게도, 제가 본 (그리고 본) 대부분의 간단한 프로그래밍 예시들은 이러한 인식을 어느 정도 강화시킵니다.
즉, SOAP는 데이터 워크플로우에 의해 추진되는 대규모 프로세스의 일부로 여러 SOAP 서비스를 함께 결합하기 시작할 때 정말 빛을 발합니다(기업용 소프트웨어를 생각해 보십시오).이것은 SOAP 프로그래밍 예시들 중 많은 것이 전달하지 못하는 이유는 주식의 가격을 가져오는 것과 같은 어떤 것을 하는 단순한 SOAP 연산은 입력을 위해 정해진 데이터 형식과 함께 특정한 기능을 세부적으로 제공하는 기계로 읽을 수 있는 API를 제공하는 맥락에서 제시되지 않는 한 일반적으로 스스로 수행하는 일에 대해 지나치게 복잡하기 때문입니다.s 및 출력은 더 큰 프로세스에 의해 스크립트로 작성됩니다.
최종 제품이 어떻게 사용되는지에 대한 전체적인 맥락에서 SOAP의 장점을 보여주지 못하면 SOAP의 장점을 보여주기 어렵기 때문에 어떻게 보면 이는 SOAP에게 나쁜 평판을 주기 때문에 슬픈 일입니다.
SOAP는 웹 서비스에 대한 서비스 지향적 접근 방식을 구현합니다. 즉, 서비스와 상호 작용하는 주요 방법은 방법(또는 동사)입니다.REST는 개체(또는 명사)가 중심이 되는 자원 지향적 접근법을 취합니다.
"PHP-universe" PHP 지원은 모든 고급 SOAP에 큰 의미가 있습니다.WS-Security 또는 WS-RM 비빌트 지원을 활성화하는 경우에도 기본 요구사항을 충족하는 즉시 http://wso2.com/products/web-services-framework/php/ 같은 것을 사용하게 됩니다.
SOAP 봉투 작성은 이름 공간을 만드는 방식인 PHP에서 많이 지저분하다고 생각합니다. xsd:nil, xsd:anytype 및 SOAP 인코딩(신은 어떻게 다른지 알고 있습니다)을 SOAP 메시지에 사용하는 오래된 스타일의 SOAP 서비스.
REST를 고수함으로써 이 모든 혼란을 피하십시오. REST는 WWW가 시작된 이래로 우리가 사용해 온 큰 문제가 아닙니다.이 http://www.ics.uci.edu/ ~http/http/remission/top.htm 논문이 나왔을 때 비로소 이 논문이 어떻게 하면 HTTP 기능을 사용하여 RESTFul Services를 구현할 수 있는지를 알 수 있었습니다.HTTP는 본질적으로 REST이며, 이것은 단지 HTTP를 사용하는 것이 당신의 서비스를 RESTful로 만든다는 것을 의미하지 않습니다.
SOAP는 HTTP의 핵심 기능을 무시하고 HTTP를 단지 전송 프로토콜로 간주하므로 이론적으로 전송 프로토콜에 독립적입니다(실제로 SOAP Action 헤더에 대해 들어본 적이 있습니까? 지금은 Google이 아니라면!).
JSON 적응이 증가하고 JSON으로 REST를 성숙시키는 자바스크립트를 가진 HTML5가 서비스를 다루는 가장 일반적인 방법이 되었습니다.JSON Schema도 정의되었으며, 필요한 경우 WADL과 함께 엔터프라이즈급 솔루션(아직 초기 단계임)에 사용할 수 있습니다.
REST와 JSON에 대한 PHP 지원은 기존 내장 SOAP 지원보다 확실히 더 좋습니다.
여기에 SOA, WOA, ROA의 버즈 워드를 몇 개 더 추가합니다.
http://blog.dhananjaynene.com/2009/06/rest-soa-woa-or-roa/
http://www.scribd.com/doc/15657444/REST-White-Paper
제가 특히 WS-Security 사양에 대해 SOAP를 좋아하는 점은 좋은 사양 중 하나이며 엔터프라이즈 JSON 적응을 생각하는 사람이 필드 레벨 암호화 등 JSON을 위해 유사한 것을 제공해야 하는 경우입니다.
하나의 빠른 점 - 전송 프로토콜 및 조정;
SOAP over TCP는 ESB(오케스트레이티드 머신 투 머신 서비스) 및 외부 서비스를 포함한 속도, 안정성 및 보안상의 이유로 사용합니다.서비스 정의를 변경하면 WSDL 변경에서 오류가 발생하고 즉시 명백하며 재구성/배치할 수 있습니다.
REST에서도 그렇게 할 수 있을지 확신할 수 없습니다. 수정되거나 진행되기를 기다리고 있습니다!REST를 사용하여 서비스 정의를 변경합니다. 서비스 정의가 400(또는 무엇이든) 반환되기 전까지는 아무것도 알 수 없습니다.
서로 다른 시스템과 언어 간의 상호 운용성을 찾고 계신다면, 저는 당연히 REST를 선택하겠습니다.저는 SOAP를 사이에 두고 작업하는 데 많은 문제를 겪었습니다.예를 들어 NET과 Java가 있습니다.
어떤 것이 더 빠른지를 찾기 위한 벤치마크를 만듭니다. 다음 결과를 봅니다.
1,000개 요청의 경우:
- REST가 3초걸렸습니다.
- SOAP는 7초가 걸렸습니다.
10,000건의 요청에 대해:
- REST는 33초가 걸렸습니다.
- SOAP는 69초가 걸렸습니다.
1,000,000건의 요청에 대해:
- REST는 62초가 걸렸습니다.
- SOAP는 114초가 걸렸습니다.
오래된 질문이지만 오늘날에도 여전히 관련이 있습니다. 아직도 많은 개발자들이 사용하고 있기 때문입니다.
제 일은 사물인터넷 솔루션을 설계하고 개발하는 일입니다.여기에는 클라우드와 통신하는 소형 임베디드 장치를 위한 코드 개발도 포함됩니다.
REST는 이제 널리 받아들여지고 유용하며, 웹에 대한 사실상의 표준이며, 심지어 마이크로소프트조차 REST 지원을 Azure 전체에 포함하고 있습니다.SOAP에 의존해야 한다면 작은 내장 기기에 비해 너무 크고 부피가 크며 성가신 일을 할 수 없습니다.
REST는 단순하고 깨끗하고 작습니다.소형 임베디드 기기에 이상적입니다.WSDL을 보내주는 웹 개발자와 함께 작업할 때 항상 소리를 지릅니다. 왜 이것이 작동하지 않을 것인지, 왜 그들이 REST를 배워야 하는지에 대한 교육 캠페인을 시작해야 하기 때문입니다.
1.내 경험으로는.REST는 이미 구축된 URL에 접근할 수 있는 옵션을 제공한다고 생각합니다.예-> 구글에서 단어를 검색합니다.그 URL은 REST를 위한 웹 서비스로 사용될 수 있습니다.SOAP에서는 자체 웹 서비스를 생성하고 SOAP 클라이언트를 통해 액세스할 수 있습니다.
- REST는 텍스트, JSON, XML 형식을 지원합니다.따라서 두 애플리케이션 간의 통신에 보다 다용도적입니다.SOAP는 메시지 통신을 위한 XML 형식만 지원합니다.
언급URL : https://stackoverflow.com/questions/76595/soap-or-rest-for-web-services
'source' 카테고리의 다른 글
| 열을 삭제하려고 하면 오류 1025(HY000)가 발생합니다....(오류: 150) 이름 변경 시 오류 발생 (0) | 2023.09.17 |
|---|---|
| 모듈 'AppModule'에서 선언한 예기치 않은 값 '정의되지 않음' (0) | 2023.09.17 |
| C 전처리기에서 스트렌을? (0) | 2023.09.12 |
| 'app' Android XML 네임스페이스는 무엇입니까? (0) | 2023.09.12 |
| RunSettings 파일 내에서 TestRunParameters에 액세스하는 방법 (0) | 2023.09.12 |