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 접근법은 개발자가이 커스텀 배관을 구축하게합니다.
답변
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에 관심이 있습니까?
계속해야합니까?
