REST가 웹 서비스를 수행하는 더 나은 접근입니까? 아니면 SOAP입니까? 아니면 다른 문제에 대한 다른 도구입니까? 아니면 미묘한 문제입니까? 즉, 특정 경기장에서 다른 경기장보다 약간 더 낫습니까?

특히 이러한 개념에 대한 정보와 PHP- 유니버설 및 최신 고급 웹 응용 프로그램과의 관계에 대해 감사하겠습니다.

필자는 Hewlett-Packard에서 작업 할 때 원래 사양에서 코드 생성 및 WSDL 생성을 포함한 첫 번째 SOAP 서버 중 하나를 구축했습니다. 나는 아무것도 SOAP를 사용하지 않는 것이 좋습니다.

약어 "SOAP"는 거짓말입니다. 단순하지 않고 객체 지향적이 아니며 액세스 규칙을 정의하지 않습니다. 틀림없이 그것은 의정서입니다. 그것은 돈 박스의 최악의 사양이며, 그는 "COM"을 범한 사람이기 때문에 매우 위업입니다.

SOAP에는 전송을위한 REST, JSON, XML 또는 데이터 표현을위한 일반 텍스트로는 수행 할 수없는 유용한 기능이 없습니다. 전송 보안을 위해 https를 사용할 수 있습니다. 인증을 위해 기본 인증. 세션에는 쿠키가 있습니다. REST 버전은 더 단순하고 명확하며 빠르게 실행되며 더 적은 대역폭을 사용합니다.

XML-RPC는 요청, 응답 및 오류 프로토콜을 명확하게 정의하며 대부분의 언어에 적합한 라이브러리가 있습니다. 그러나 XML은 많은 작업에 필요한 것보다 무겁습니다.

REST는 아키텍처이고 SOAP은 프로토콜입니다.

이것이 첫 번째 문제입니다.

REST 애플리케이션에서 SOAP 엔벨로프를 보낼 수 있습니다.

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의 경우 네 개의 동사는 해당 HTTP 요청에 맵핑되고 명사는 URL로 식별됩니다. 이로 인해 상태 관리가 SOAP보다 훨씬 투명 해집니다. 서버의 상태와 클라이언트의 상태가 불분명 한 경우가 많습니다.

실제로이 대부분은 사라지고 REST는 일반적으로 JSON으로 결과를 반환하는 간단한 HTTP 요청을 참조 하지만 SOAP은 XML을 전달하여 통신하는보다 복잡한 API입니다. 둘 다 장단점이 있지만 필자의 경험에 따르면 SOAP에서 얻는 전체 기능이 거의 필요하지 않기 때문에 REST가 일반적으로 더 나은 선택이라는 것을 알았습니다.

2012 년 질문에 대한 빠른 결론 :

REST가 실제로 잘 작동하는 영역은 다음과 같습니다.

• 제한된 대역폭 및 리소스. 반환 구조는 실제로 모든 형식 (개발자 정의)으로되어 있습니다. 또한 REST 접근법은 표준 GET, PUT, POST 및 DELETE 동사를 사용하므로 모든 브라우저를 사용할 수 있습니다. REST는 오늘날 대부분의 최신 브라우저에서 지원하는 XMLHttpRequest 객체를 사용할 수 있으며 AJAX의 추가 보너스가 추가됩니다.

• 완전히 상태 비 저장 작업  작업을 계속해야하는 경우 REST가 최선의 방법이 아니며 SOAP이 더 적합 할 수 있습니다. 그러나 상태 비 저장 CRUD (만들기, 읽기, 업데이트 및 삭제) 작업이 필요한 경우 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 Data Services와 같은 클라이언트 작성에 도움이됩니다. 그러나 대부분의 경우 공구 지원이 부족합니다.

SOAP은 툴링 관점에서 유용하다. WSDL은 툴에 의해 쉽게 소비되기 때문이다. 따라서 원하는 언어로 웹 서비스 클라이언트를 생성 할 수 있습니다.

REST는 AJAX'y 웹 페이지와 잘 작동합니다. 요청을 단순하게 유지하면 JavaScript에서 직접 서비스를 호출 할 수 있으며 매우 유용합니다. 응답 XML에 네임 스페이스가 없도록하십시오. 브라우저가 그 네임 스페이스에 질식하는 것을 보았습니다. 따라서 xsi : type은 아마도 당신을 위해 작동하지 않을 것입니다. 지나치게 복잡한 XML 스키마는 없습니다.

REST는 성능이 더 좋은 경향이 있습니다. REST 응답을 생성하는 코드의 CPU 요구 사항은 SOAP 프레임 워크가 표시하는 것보다 낮은 경향이 있습니다. 또한 서버 측에 XML 생성 덕이 정렬되어 있으면 XML을 클라이언트로 효과적으로 스트리밍 할 수 있습니다. 따라서 데이터베이스 커서 행을 읽는다고 가정하십시오. 행을 읽을 때 행을 XML 요소로 형식화하고이를 서비스 소비자에게 직접 작성합니다. 이런 식으로 XML 출력을 쓰기 전에 메모리에서 모든 데이터베이스 행을 수집 할 필요는 없습니다. 동시에 읽고 쓸 수 있습니다. REST를 위해 스트리밍을 작동 시키려면 새로운 템플릿 엔진 또는 XSLT를 살펴보십시오.

반면에 SOAP는 도구로 생성 된 서비스에서 큰 얼룩으로 생성 된 다음 작성하는 경향이 있습니다. 이것은 절대 사실이 아닙니다. 첨부 파일을 사용하는 것과 같이 SOAP에서 스트리밍 특성을 얻는 방법이 있습니다.

내 의사 결정 과정은 다음과 같습니다. 소비자가 서비스를 쉽게 도구화하고 작성하는 메시지가 중소형 (10MB 이하)이고 추가 CPU를 구울 염려가 없다면 서버에서 순환하면 SOAP를 사용합니다. 웹 브라우저에서 AJAX에 서비스를 제공해야하거나 스트리밍해야하거나 응답이 엄청 나면 REST를 사용합니다.

마지막으로 WS-Security 및 상태 저장 웹 서비스와 같이 SOAP를 중심으로 구축 된 훌륭한 표준이 많이 있습니다. 올바른 도구를 사용하는 경우 연결할 수 있습니다. 그런 종류의 물건은 실제로 차이를 만들고 약간의 털이 많은 요구 사항을 충족시키는 데 도움이 될 수 있습니다.

나는 이것이 오래된 질문이라는 것을 알고 있지만 내 대답을 게시해야합니다. 어쩌면 누군가가 유용하다고 생각할 것입니다. SOAP보다 REST를 권장하는 사람이 몇 명인지 믿을 수 없습니다. 나는이 사람들이 개발자가 아니거나 실제로 합리적인 크기의 REST 서비스를 구현하지 않았다고 가정 할 수 있습니다. REST 서비스를 구현하면 SOAP 서비스를 구현하는 것보다 많은 시간이 걸립니다. 그리고 결국 그것은 훨씬 더 지저분 해집니다. SOAP 99 %를 선택하는 이유는 다음과 같습니다.

1) REST 서비스를 구현하는 데 SOAP 서비스를 구현하는 것보다 시간이 오래 걸립니다. 모든 현대 언어 / 프레임 워크 / 플랫폼이 WSDL에서 읽고 프록시 클래스와 클라이언트를 출력하는 도구가 있습니다. REST 서비스 구현은 수작업으로 수행되며이를 통해 문서를 읽으십시오. 또한이 두 가지 서비스를 구현하는 동안 실제 스키마 나 참조 문서가 없기 때문에 파이프를 통해 무엇이 돌아올 지에 대해 "추측"해야합니다.

2) XML을 반환하는 REST 서비스를 작성하는 이유는 무엇입니까? 유일한 차이점은 REST를 사용하면 각 요소 / 속성이 나타내는 유형을 알지 못한다는 것입니다. 자신의 구현을 통해 언젠가는 항상 int라고 생각한 필드에서 문자열이 나오지 않기를 바랍니다. SOAP는 WSDL을 사용하여 데이터 구조를 정의하므로 이는 쉬운 일이 아닙니다.

3) SOAP를 사용하면 SOAP Envelope의 "오버 헤드"가 있다는 불만을 들었습니다. 이 시대에 우리는 실제로 몇 바이트에 대해 걱정할 필요가 있습니까?

4) REST를 사용하면 URL을 브라우저에 넣고 데이터를 볼 수 있다는 주장을 들었습니다. REST 서비스가 단순 인증을 사용하거나 인증을 사용하지 않는 경우에는 물론입니다. 예를 들어 Netflix 서비스는 OAuth를 사용하므로 요청을 제출하기 전에 서명하고 인코딩해야합니다.

5) 각 리소스에 대해 "읽을 수있는"URL이 필요한 이유는 무엇입니까? 서비스를 구현하기 위해 도구를 사용하는 경우 실제 URL에 관심이 있습니까?

계속해야합니까?

필자가 작성한 대부분의 응용 프로그램은 서버 측 C # 또는 Java 또는 WinForms 또는 WPF의 데스크톱 응용 프로그램입니다. 이러한 애플리케이션은 REST가 제공 할 수있는 것보다 더 풍부한 서비스 API가 필요한 경향이 있습니다. 또한 웹 서비스 클라이언트를 만드는 데 몇 분 이상 걸리지 않습니다. WSDL 처리 클라이언트 생성 도구를 사용하면 클라이언트를 구현하고 비즈니스 가치를 추가 할 수 있습니다.

이제 일부 자바 스크립트 아약스 호출에 대해 명시 적으로 웹 서비스를 작성한다면 아마도 REST에있을 것입니다. 클라이언트 기술을 알고 JSON을 활용하기 위해서입니다. 내 의견으로는, 자바 스크립트에서 사용되는 웹 서비스 API는 아마도 복잡하지 않아야합니다.이 유형의 복잡성은 서버 측에서 더 잘 처리되는 것처럼 보입니다.

자바 스크립트를위한 SOAP 클라이언트가있다. jQuery에 하나가 있다는 것을 알고 있습니다. 따라서 Javascript에서 SOAP 를 활용할 수 있습니다. JSON 문자열을 반환하는 REST 서비스만큼 좋지 않습니다. 따라서 임의의 수의 클라이언트 기술과 사용에 융통성이있을 정도로 복잡하고 복잡한 웹 서비스를 원한다면 SOAP을 사용합니다.

Java를 사용하는 경우 JAX-RS와 Jersey를 보면 REST를 먼저 사용하는 것이 좋습니다. 구현을 . REST는 많은 언어에서 훨씬 간단하고 쉽게 조작 할 수 있습니다.

이 스레드에서 다른 사람들이 말했듯이 SOAP의 문제는 다른 WS- * 사양이 들어오고 WSDL, XSD, SOAP, WS-Addressing 등의 잘못된 부분을 벗어나면 수많은 interop 문제가있을 때의 복잡성입니다.

REST v SOAP 토론을 판단하는 가장 좋은 방법은 인터넷을 살펴 보는 것입니다. 웹 공간, Google, Amazon, ebay, Twitter 등의 거의 모든 주요 업체는 SOAP보다 RESTful API를 사용하고 선호하는 경향이 있습니다.

REST를 사용하는 또 다른 좋은 방법은 웹 응용 프로그램과 REST 프런트 엔드간에 많은 코드와 인프라를 재사용 할 수 있다는 것입니다. 예를 들어 JAX-RS 및 암시 적 뷰와 같은 프레임 워크를 사용하면 일반적으로 HTML과 XML을 비교하여 리소스를 JSON으로 렌더링하는 것이 매우 쉽습니다.

돈 박스가 농담으로 SOAP를 만들었 을 것입니다. 웹을 통해 RPC 메소드를 호출 '과 오늘날 웹 표준의 악몽이 무엇인지 깨달았을 때 신음한다 :-)

REST는 훌륭하고 간단하며 어디에서나 빠르고 쉽게 구현할 수 있습니다 (표준보다 '표준'). REST를 사용하십시오.

둘 다 자신의 자리가 있다고 생각합니다. 내 의견으로는 :

SOAP : WS-* (보안, 정책 등)가 적합한 기본 계층에서 레거시 / 임계 시스템과 웹 / 웹 서비스 시스템 간의 통합을위한 더 나은 선택입니다.

RESTful : 공개 API와 함께 웹 사이트 사이의 통합을위한 최상의 선택 (VIEW, 즉, URI를 호출하는 자바 스크립트)

언급되지 않은 한 가지는 SOAP 봉투가 본문 부분뿐만 아니라 헤더를 포함 할 수 있다는 것입니다. 이를 통해 XML의 전체 표현성을 사용하여 대역 외 정보를 보내고받을 수 있습니다. 내가 아는 한 REST는 HTTP 헤더 및 결과 코드로 제한합니다.

(이제 REST 서비스와 함께 쿠키를 사용하여 "헤더"유형의 대역 외 데이터를 보낼 수 있습니까?)

XML-RPC를 간과하지 마십시오. 가벼운 솔루션을 사용하고 있다면 몇 페이지의 텍스트로 정의되고 최소량의 코드로 구현 될 수있는 프로토콜에 대해 언급해야 할 것이 많습니다. XML-RPC는 수년 동안 존재 해 왔지만 한동안 유행을 벗어났습니다.

2012 년에 답변을하면 (두 번째 현상금으로) 새로운 결과를보고 오늘의 결과를 검토합니다 (기타 답변).

SOAP, 장단점

SOAP 1.2, 장점과 2007 년부터 "REST"... 음,에 비해 단점에 대해 당신이 WSDL와 REST 웹 서비스를 설명 할 수 는 좀 더 열심히 작업하는 경우, 그리고 SOAP 프로토콜을 사용하여 ... 즉,이다 의 모든 W3C 표준 웹 서비스 프로토콜 스택 은 REST 일 수 있습니다 !

모든 철학적, 방법 론적 논의가 일시적으로 회피되는 시나리오를 상상할 수 있기 때문에 좋은 출발점입니다. 유사한 서비스에서 기술적으로 "SOAP-REST"와 "NON-SOAP-REST"를 비교할 수 있습니다.

• SOAP-REST (= "REST-SOAP") : L.Mandel이 보여준 것처럼 WSDL2는 REST 웹 서비스를 설명 할 수 있으며, 예시 된 XML을 SOAP로 묶을 수 있다고 가정하면 모든 구현은 "SOAP-REST"가됩니다. .

• NON-SOAP-REST : SOAP 가 될 수없는 모든 REST 웹 서비스 ... 즉, 잘 알려진 REST 예제의 "90 %"입니다. 일부는 XML을 사용하지 않고 (예 : 일반적인 AJAX REST는 JSON을 대신 사용) SOAP 헤더 나 규칙없이 다른 XML 구조를 사용합니다. 추신 : 비공식 성을 피하기 위해 비교에서 REST 레벨 2 를 가정 할 수 있습니다 .

물론 더 개념적으로 비교하려면 다른 모델링 방식으로 "NON-REST-SOAP"과 "NON-SOAP-REST"를 비교하십시오. 웹 서비스 분류를 완료하면 다음과 같습니다.

• NON-REST-SOAP : REST 웹 서버가 될 수없는 SOAP 웹 서비스 ... 잘 알려진 SOAP 예제의 "90 %".

• NON-REST-NEITHER-SOAP : 예. "웹 서비스 모델링"의 세계는 다른 것들 (예 : XML-RPC )로 구성됩니다.

REST 예측에서의 SOAP

비교 가능한 것들 비교 : SOAP-REST 와 NON-SOAP-REST 비교 .

찬성

몇 가지 용어를 설명하면

• 계약 안정성 : 모든 종류의 계약 ( "서면 된 계약")

  • 표준 사용 : 모든 수준의 W3C 스택 은 상호 호환됩니다. 반면에 REST는 W3C 또는 ISO 표준이 아니며 서비스 주변 장치에 대한 표준화 된 세부 정보가 없습니다. 그래서,로 I , @DaveWoldrich (20 표), @cynicalman (5), @Exitos (0) 표준의 필요성이 맥락에서, 전에 말했듯이, 당신은 SOAP이 필요합니다.

  • 에 의해 모범 사례의 사용 다음의 "자세한 측면" W3C 스택 구현, 관련 인간 / 법률 / juridic 계약을 변환합니다.

• 견고성 : SOAP 구조와 헤더의 안전성. 메타 데이터 커뮤니케이션 (XML의 완전한 표현성)과 검증 을 통해 변경이나 소음에 대한 "보험 정책"을 갖습니다.
  SOAP는 "트랜잭션 신뢰성 (...)은 통신 장애를 처리합니다. SOAP는 재시도 로직에 대해 더 많은 제어를 가지므로 더 많은 종단 간 안정성 및 서비스 보장을 제공 할 수 있습니다"라고 E. Terman 은 말합니다 .

인기순으로 정렬 전문가,

• 더 나은 도구 (~ 70 표) : SOAP는 현재 잘 정의되고 널리 채택 된 표준이기 때문에 2007 년부터 2012 년 이후로 더 나은 도구를 사용하고 있습니다. @MarkCidade (27 투표), @DaveWoldrich (20), @JoshM (13), @TravisHeseman (9)를 참조하십시오.

• 표준 준수 (25 표) : I , @DaveWoldrich (20 표), @cynicalman (5), @Exitos (0)는 앞서 말한 것처럼 표준이 필요한 상황에서는 SOAP이 필요합니다.

• 견고성 : SOAP 헤더 보험, @JohnSaunders (8 투표).

단점

• SOAP 구조는 더 복잡합니다 (300 표 이상). 여기의 모든 답변과 "SOAP vs REST"에 대한 소스는 SOAP의 중복성과 복잡성에 어느 정도 싫어합니다. 이는 공식 검증 (아래 참조) 및 견고성 (위 참조 ) 요구 사항의 자연스러운 결과입니다 . "REST NON-SOAP"(및 SOAP 생성자 인 XML-RPC )은 더 단순하고 비공식적입니다.

• "XML 전용"제한은 작은 서비스 (~ 50 표)를 사용할 때 성능 장애입니다 . json.org/xml 및 이 질문 또는 다른 질문을 참조하십시오 . 이 점은 @toluju (41) 및 기타에 의해 표시됩니다.
  추신 : JSON은 IETF 표준이 아니기 때문에 웹 소프트웨어 커뮤니티의 사실상의 표준 을 고려할 수 있습니다 .

SOAP를 사용한 모델링 서비스

이제 NON-SOAP-REST 비교 와 함께 SOAP-NON-REST 를 추가하고 SOAP 를 사용하는 것이 더 좋은시기를 설명 할 수 있습니다 .

• 표준 및 안정적인 계약이 필요합니다 ( "PROS"섹션 참조). 추신 : @saille에 설명 된 일반적인 "B2B 표준 필요"를 참조하십시오 .

• 도구가 필요합니다 ( "PROS"섹션 참조). 추신 : 표준 및 공식 검증 의 존재 (아래 참조)는 도구 자동화의 중요한 문제입니다.

• 병렬 대량 처리 (아래의 "컨텍스트 / 파운데이션"섹션 참조) : 프로세스가 더 크거나 더 느린 경우 SOAP의 복잡성에 관계없이 안정성과 안정성이 최선의 투자입니다.

• 더 많은 보안 이 필요합니다 : HTTPS 이상이 필요하고 보호를위한 추가 기능이 필요한 경우 SOAP가 더 나은 선택입니다 ( @Bell , 32 표 참조 ). "요청 / 응답보다 더 복잡한 경로를 따라 또는 HTTP를 포함하지 않는 전송을 통해 메시지를 보내기", S. Seely . XML은 XML 암호화 , XML 서명 및 XML 정규화에 대한 표준을 제공하는 핵심 문제이며 SOAP을 통해서만 WS-Security 와 같이 잘 받아 들여진 표준으로 이러한 메커니즘을 메시지에 포함시킬 수 있습니다 .

• 더 많은 유연성이 필요합니다 (제한이 적음) : SOAP은 URI와 정확히 일치 할 필요가 없습니다. HTTP로 제한해서는 안됩니다. 4 동사로 제한 할 필요가 없습니다. @TravisHeseman (9 votes)에 따르면, "임의의 수의 클라이언트 기술 및 용도에 융통성있는"것을 원한다면 SOAP를 사용하십시오.
  추신 : XML은 JSON보다 보편적이며 표현력이 뛰어납니다.

• 공식적인 검증 필요 : W3C 스택 이 공식적인 방법을 사용 하고 REST가 더 비공식적 임을 이해하는 것이 중요합니다 . WSDL ( 공식 언어 ) 서비스 설명은 웹 서비스 인터페이스 의 공식 사양 이며 SOAP는 가능한 모든 WSDL 처방을 수용하는 강력한 프로토콜입니다.

문맥

역사적인

추세를 평가하려면 역사적 관점이 필요합니다. 이 주제의 경우 10 년 또는 15 년의 관점 ...

W3C 표준화 이전에는 무정부 상태가있다. 서로 다른 프레임 워크로 상호 운용 가능한 서비스를 구현하기가 어려웠으며 회사간에 상호 운용 가능한 것을 구현하기가 더 어렵고 비용이 많이 들고 시간이 많이 소요되었습니다. W3C 스택 표준은 빛, 복잡한 웹 서비스 세트의 상호 운용을위한 북쪽이었다.

AJAX를 구현하는 것과 같은 일상적인 작업의 경우 SOAP는 무겁습니다. 따라서 간단한 접근 방식의 필요성은 새로운 이론 프레임 워크를 선택해야합니다. 또한 Google, Amazon, Yahoo 등은 REST 대안 인 최상의 대안을 선택했습니다. 이러한 맥락에서 REST 개념이 "경쟁 프레임 워크"로 도착했으며 오늘날 (2012 년)이 대안은 사실상의 표준입니다. 프로그래머에게 입니다.

기초

병렬 컴퓨팅 의 맥락 에서 웹 서비스는 병렬 서브 태스크를 제공합니다. SOAP와 같은 프로토콜은 우수한 동기화 및 통신을 보장합니다. "모든 작업"이 아님 : 웹 서비스는
거칠고 창피한 병렬 처리 로 분류 될 수 있습니다 .

과제가 커짐에 따라 "복잡성 토론"이 덜 중요 해지고 의사 소통의 견고성과 계약의 견고성이 더욱 중요해집니다.

미묘한 차이가 있습니다.

서비스와 다른 시스템 인터페이스가 필요한 경우 계약, WSDL 및 SOAP 표준에 대한 "확인"계층으로 인해 많은 클라이언트가 SOAP에 대해 더 만족할 것입니다.

시스템을 호출하는 일상적인 시스템의 경우 간단한 HTML 호출로 SOAP가 불필요한 오버 헤드가 많다고 생각합니다.

나는 똑같은 것을보고 있으며, 그들은 다른 문제에 대한 다른 도구 라고 생각 합니다 .

SOAP (Simple Object Access Protocol) 표준 메시지 아키텍처 및 메시지 형식을 정의하는 XML 언어는 작업에 대한 설명이 포함 된 웹 서비스에서 사용됩니다. WSDL은 웹 서비스를 설명하고 액세스하는 방법에 대한 XML 기반 언어입니다. SMTP, HTTP, FTP 등에서 실행됩니다. WSDL + XSD와 같은 서비스를 정의하기 위해 미들웨어 지원, 잘 정의 된 메커니즘이 필요합니다. WS-Policy SOAP는 XML 기반 데이터를 리턴합니다. SOAP는 보안 및 안정성에 대한 표준을 제공합니다.

REST (Representational State Transfer) 웹 서비스. 이들은 2 세대 웹 서비스입니다. RESTful 웹 서비스는 SOAP 기반 서비스보다 HTTP를 통해 통신하며 XML 메시지 또는 WSDL 서비스 API 정의가 필요하지 않습니다. REST의 경우 미들웨어가 필요하지 않으며 HTTP 지원 만 필요합니다 .WADL Standard, REST는 XML, 일반 텍스트, JSON, HTML 등을 반환 할 수 있습니다.

많은 유형의 클라이언트가 RESTful 웹 서비스를 사용하는 것이 더 쉬우면서 서버 측은 진화하고 확장 할 수 있습니다. 고객은 서비스의 일부 또는 전부를 소비하고 다른 웹 기반 서비스와 통합 할 수 있습니다.

1. REST는 표준 HTTP를 사용하므로 클라이언트를 작성하고 API를 개발하는 것이 더 간단합니다.
2. REST는 SOAP로 XML 만 허용하는 XML, 일반 텍스트, JSON, HTML과 같은 다양한 데이터 형식을 허용합니다.
3. REST는 성능과 확장 성이 향상되었습니다.
4. 휴식을 취하고 캐시 할 수 있으며 SOAP을 사용할 수 없습니다
5. SOAP에 오류 처리가없는 내장 오류 처리
6. REST는 특히 유용한 PDA 및 기타 모바일 장치입니다.

REST는 기존 웹 사이트와 쉽게 통합 할 수있는 서비스입니다.

SOAP에는 보안 및 안정성에 대한 표준을 제공하고 다른 WS 준수 클라이언트 및 서버와 상호 운용되는 프로토콜 세트가 있습니다. SOAP 웹 서비스 (예 : JAX-WS)는 비동기 처리 및 호출을 처리하는 데 유용합니다.

복잡한 API의 경우 SOAP가 더 유용합니다.

REST는 Roy Fielding이 발명 한 아키텍처로 논문 아키텍처 스타일 및 네트워크 기반 소프트웨어 아키텍처 디자인에 설명되어 있습니다. Roy는 또한 HTTP 의 주요 저자입니다 월드 와이드 웹을 통한 문서 전송을 정의하는 프로토콜 . HTTP는 RESTful 프로토콜입니다. 개발자가 "REST 웹 서비스 사용"에 대해 이야기 할 때 "HTTP 사용"이라고 말하는 것이 더 정확할 것입니다.

SOAP는 HTTP 요청 / 응답 내부에서 터널링하는 XML 기반 프로토콜이므로 SOAP을 사용하더라도 REST도 사용합니다. SOAP가 기본 HTTP에 중요한 기능을 추가하는지에 대한 논쟁이 있습니다.

웹 서비스를 작성하기 전에 HTTP를 공부하는 것이 좋습니다. 홀수는 스펙에 이미 정의 된 기능으로 요구 사항을 구현할 수 있으므로 다른 프로토콜이 필요하지 않습니다.

나는 같은 문제를보고있다. 실제로 REST는 빠르고 쉽고 쉽고 가벼운 호출 및 응답에 좋고 디버깅에 좋습니다 (URL을 브라우저로 펌핑하고 응답을 보는 것보다 낫습니다).

그러나 REST가 떨어지는 것처럼 보이는 것은 표준이 아니라는 사실과 관련이 있습니다 (표준으로 구성되어 있음에도 불구하고). 대부분의 프로그래밍 라이브러리에는 WSDL을 검사하여 SOAP 기반 서비스를 사용하는 데 필요한 클라이언트 코드를 자동으로 생성하는 방법이 있습니다. 지금까지 REST 기반 웹 서비스를 많이 사용하는 것은 가능한 호출과 일치하는 인터페이스를 작성하는 더 임시 접근 방식으로 보입니다. 수동 http 요청을 한 후 응답을 구문 분석하십시오. 이것은 그 자체로 위험 할 수 있습니다.

SOAP의 장점은 일단 WSDL이 발행되면 비즈니스는 인터페이스 변경을 계약으로 설정하는 논리 대립을 구성하여 wsdl을 변경할 수 있다는 것입니다. manouvre를위한 공간이 없습니다. 해당 WSDL에 대해 모든 요청의 유효성을 검증 할 수 있습니다. 그러나 WSDL이 REST 서비스를 올바르게 설명하지 않기 때문에 통신 인터페이스에 동의하는 정의 된 방법이 없습니다.

비즈니스 관점에서 이것은 의사 소통을 해석과 변화에 대해 개방적인 것으로 보이며 이는 나쁜 생각처럼 보입니다.

이 스레드에서 맨 위의 '답변'은 SOAP가 단순 객체 지향 액세스 프로토콜 (Simple Object-Oriented Access Protocol)을 나타내는 것으로 보이지만 위키를 보면 O는 객체 지향이 아닙니다. 그들은 다른 것입니다.

이 게시물이 매우 오래되었다는 것을 알고 있지만 내 조사 결과에 응답해야한다고 생각했습니다.

좋은 질문입니다 ... 나는 당신을 타인으로 이끌고 싶지 않기 때문에 다른 사람들의 대답에 당신도 많이 열려 있습니다. 저에게는 실제로 오버 헤드 비용과 API 사용에 달려 있습니다. 클라이언트 소프트웨어를 만들 때 웹 서비스를 사용하는 것을 선호하지만 SOAP의 무게는 마음에 들지 않습니다. REST는 무게가 가볍지 만 클라이언트 관점에서 작업하는 것을 좋아하지 않습니다.

다른 사람들의 생각이 궁금합니다.

이 팟 캐스트 를 듣고 찾으십시오. 당신이 듣지 않고 답을 알고 싶다면, 그 REST. 그러나 나는 정말로 듣는 것을 추천합니다.

내 일반적인 규칙은 브라우저 웹 클라이언트가 서비스에 직접 연결되도록하려면 REST를 사용해야한다는 것입니다. 백엔드 서비스간에 구조화 된 데이터를 전달하려면 SOAP를 사용하십시오.

SOAP는 때때로 설정하기가 매우 어려울 수 있으며 간단한 웹 클라이언트 및 서버 데이터 교환에 너무 과도합니다. 불행히도, 내가 본 (그리고 배운) 가장 간단한 프로그래밍 예제는이 인식을 다소 강화합니다.

즉, 데이터 워크 플로 (엔터프라이즈 소프트웨어 생각)로 구동되는 더 큰 프로세스의 일부로 여러 SOAP 서비스를 결합하기 시작하면 SOAP가 실제로 빛을 발합니다. 이것은 주식 가격을 가져 오는 것과 같은 간단한 SOAP 작업이 일반적으로 기계를 제공하는 맥락에서 제시되지 않는 한 자체적으로 수행하는 작업에 대해 지나치게 복잡하기 때문에 많은 SOAP 프로그래밍 예제가 전달하지 못하는 것입니다. 더 큰 프로세스에 의해 스크립팅되는 입력 및 출력에 대한 데이터 형식을 설정하여 특정 기능을 자세히 설명하는 읽기 가능한 API.

최종 제품이 어떻게 사용되는지에 대한 전체적인 맥락에서 SOAP의 이점을 제시하기가 어렵 기 때문에 SOAP에 대한 평판이 나쁘기 때문에 이는 슬픈 일입니다.

SOAP 는 웹 서비스에 대한 서비스 지향 접근 방식을 구현합니다.이 방식은 서비스와 상호 작용하는 기본 방법입니다. REST 는 오브젝트 (또는 명사)가 중심이되는 자원 지향 접근법을 사용합니다.

"PHP-universe"와 관련하여 모든 고급 SOAP에 대한 PHP 지원은 많은 시간을 소비합니다. WS-Security 또는 WS-RM을 기본적으로 지원하지 않아도 기본 요구 사항을 충족하자마자 http://wso2.com/products/web-services-framework/php/ 와 같은 것을 사용하게됩니다.

SOAP 엔벨로프 생성 필자는 PHP에서 네임 스페이스, xsd : nil, xsd : anytype 및 SOAP 메시지에서 SOAP 인코딩 (하나님이 어떻게 다른지 알고 있음)을 사용하는 구식 비누 서비스를 생성하는 방식에있어 매우 혼란 스럽다고 생각합니다.

REST를 고수함으로써 이러한 혼란을 피하십시오. REST는 WWW가 시작된 이래로 우리가 사용했던 것보다 큰 것은 아닙니다. 우리는이 http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm 논문이 나왔을 때만 HTTP 기능을 사용하여 RESTFul Services를 구현하는 방법을 보여줍니다. HTTP는 본질적으로 REST이므로 HTTP를 사용하여 서비스를 RESTFul로 만드는 것은 아닙니다.

SOAP는 HTTP의 핵심 기능을 무시하고 HTTP를 전송 프로토콜로 간주하므로 이론적으로 독립적 인 전송 프로토콜입니다 (실제로는 SOAP Action 헤더에 대해 들어 본 적이 있습니까? 지금 구글이 아니라면!).

JSON 적응이 증가하고 자바 스크립트가 포함 된 HTML5가있는 HTML5는 JSON을 사용하여 REST를 처리하는 가장 일반적인 방법이되었습니다. JSON 스키마는 필요한 경우 WADL과 함께 엔터프라이즈 급 솔루션 (아직 초기 단계)에도 사용할 수 있도록 정의되었습니다.

REST 및 JSON에 대한 PHP 지원은 기존의 내장 SOAP 지원보다 확실히 좋습니다.

여기에 BUZZ 단어를 몇 개 더 추가하기 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를 좋아한다는 점에서 이것은 좋은 사양 중 하나이며 Enterprise JSON 적응을 생각하는 사람이 필드 레벨 암호화 등과 같이 JSON과 비슷한 것을 정의 해야하는 경우가 있습니다.

하나의 빠른 포인트-전송 프로토콜 및 오케스트레이션;

조정 된 머신 대 머신 서비스 (ESB) 및 외부 서비스를 포함하여 속도, 안정성 및 보안상의 이유로 SOAP over TCP를 사용합니다. 서비스 정의를 변경하면 오케스트레이션에서 WSDL 변경으로 인한 오류가 발생하고 즉시 명백해지며 재 구축 / 배포 할 수 있습니다.

REST로 동일한 작업을 수행 할 수 있는지 확실하지 않습니다. 수정 또는 코스가 기다리고 있습니다! REST를 사용하여 서비스 정의를 변경하십시오. 400 (또는 무엇이든)을 리턴 할 때까지 그에 대한 정보는 없습니다.

다른 시스템과 언어 간의 상호 운용성을 찾고 있다면 확실히 REST를 사용합니다. 예를 들어 .NET과 Java 간의 SOAP 작동을 시도하는 데 많은 문제가 있습니다.

나는 그들 중 어느 것이 더 빠른지 찾기위한 벤치 마크를 만듭니다! 나는이 결과를 본다 :

1000 회 요청 :

• REST가 3 초 걸렸습니다
• SOAP는 7 초 걸렸다

10,000 건의 요청 :

• REST는 33 초 걸렸다
• SOAP는 69 초 걸렸다

1,000,000 건 요청 :

• REST는 62 초 걸렸습니다
• SOAP는 114 초 걸렸다

오래된 질문이지만 오늘날에도 여전히 관련이 있습니다 .... 엔터프라이즈 공간의 많은 개발자들이 여전히 그것을 사용하고 있기 때문입니다.

저는 IoT (Internet of Things) 솔루션을 설계하고 개발하는 작업을 수행했습니다. 여기에는 클라우드와 통신하는 소형 임베디드 장치 용 코드 개발이 포함됩니다.

REST는 이제 널리 받아 들여지고 유용하며 웹에 대한 사실상의 표준과 거의 동일하며 Microsoft에도 Azure 전체에 REST 지원이 포함되어 있습니다. SOAP에 의존해야한다면 작은 임베디드 장치에 비해 너무 크고 부피가 크고 성가신 것처럼 내가해야 할 일을 할 수 없었습니다.

REST는 단순하고 깨끗하며 작습니다. 소형 임베디드 장치에 이상적입니다. 나는 WSDL을 보내는 웹 개발자와 일할 때 항상 비명을 지른다. 왜 이것이 효과가 없는지, 왜 그들이 REST를 배워야하는지에 대한 교육 캠페인을 시작해야 할 것입니다.

1. 내 경험에서. REST가 이미 작성된 URL에 액세스하는 옵션을 제공한다고 말하고 싶습니다. 예-> Google에서 단어 검색. 해당 URL은 REST의 웹 서비스로 사용될 수 있습니다. SOAP에서는 자체 웹 서비스를 작성하고 SOAP 클라이언트를 통해 액세스 할 수 있습니다.

2. REST는 text, JSON, XML 형식을 지원합니다. 따라서 두 응용 프로그램 간 통신에보다 다양한 기능을 제공합니다. SOAP는 메시지 통신을 위해 XML 형식 만 지원합니다.