[rest] SOAP 대 REST (차이)

웹 서비스 통신 프로토콜로서 SOAP와 REST의 차이점에 대한 기사를 읽었지만 SOAP에 비해 REST의 가장 큰 장점은 다음과 같습니다.

REST는보다 동적이며 UDDI (Universal Description, Discovery 및 Integration)를 작성하고 업데이트 할 필요가 없습니다.
REST는 XML 형식으로 만 제한되지 않습니다. RESTful 웹 서비스는 일반 텍스트 / JSON / XML을 보낼 수 있습니다.

그러나 SOAP는보다 표준화되어 있습니다 (예 : 보안).

그렇다면이 점에서 정확합니까?

답변

불행히도 REST와 관련하여 많은 잘못된 정보와 오해가 있습니다. 귀하의 질문과 @cmd 의 답변 뿐만 아니라 Stack Overflow의 주제와 관련된 대부분의 질문과 답변이 반영됩니다.

SOAP와 REST는 직접 비교할 수 없습니다. 첫 번째는 프로토콜 (또는 최소한 시도)이고 두 번째는 아키텍처 스타일이기 때문입니다. 사람들은 SOAP가 아닌 HTTP API를 REST로 부르는 경향이 있기 때문에 아마도 혼동의 원인 중 하나 일 것입니다.

SOAP와 REST의 주요 차이점은 클라이언트와 서버 구현 간의 연결 정도입니다. SOAP 클라이언트는 서버에 밀접하게 연결된 사용자 정의 데스크탑 응용 프로그램처럼 작동합니다. 클라이언트와 서버 사이에 엄격한 계약이 있으며 양쪽이 변경되면 모든 것이 깨질 것으로 예상됩니다. 변경 후에는 지속적인 업데이트가 필요하지만 계약을 준수하는지 확인하는 것이 더 쉽습니다.

REST 클라이언트는 브라우저와 비슷합니다. 프로토콜 및 표준화 된 방법을 사용하는 방법을 알고있는 일반 클라이언트이며, 그 안에 응용 프로그램이 적합해야합니다. 추가 메소드를 작성하여 프로토콜 표준을 위반하지 않고 표준 메소드를 활용하여 매체 유형에서 조치를 작성합니다. 올바르게 수행하면 커플 링이 줄어들고 변경 사항을보다 정교하게 처리 할 수 있습니다. 클라이언트는 진입 점 및 미디어 유형을 제외하고 API에 대한 지식이 전혀없는 REST 서비스를 시작해야합니다. SOAP에서 클라이언트는 사용할 모든 것에 대한 사전 지식이 필요하거나 상호 작용을 시작하지도 않습니다. 또한 서버 자체에서 제공하는 주문형 코드로 REST 클라이언트를 확장 할 수 있습니다.

REST가 무엇인지, SOAP와 어떻게 다른지 이해하는 데 중요한 포인트라고 생각합니다.

REST는 프로토콜 독립적입니다. HTTP와 연결되어 있지 않습니다. 웹 사이트에서 ftp 링크를 따라갈 수있는 것처럼 REST 애플리케이션은 표준화 된 URI 체계가있는 모든 프로토콜을 사용할 수 있습니다.
REST는 CRUD를 HTTP 메소드에 맵핑하지 않습니다. 이에 대한 자세한 설명은 이 답변을 읽으십시오 .
REST는 사용중인 부품만큼 표준화되어 있습니다. HTTP의 보안 및 인증이 표준화되어 있으므로 REST over HTTP를 수행 할 때 사용합니다.
REST는 하이퍼 미디어 및 HATEOAS 가 없으면 REST가 아닙니다 . 즉, 클라이언트는 진입 점 URI 만 알고 있으며 리소스는 클라이언트가 따라야하는 링크를 반환해야합니다. REST API에서 할 수있는 모든 작업에 URI 패턴을 제공하는 멋진 문서 생성기는 그 요점을 완전히 벗어났습니다. 그들은 표준을 준수 해야하는 것을 문서화 할뿐만 아니라 그렇게 할 때 클라이언트가 API의 진화에서 특정 순간에 결합하고 API의 모든 변경 사항을 문서화하고 적용해야합니다. 아니면 깨질 것입니다.
REST는 웹 자체의 아키텍처 스타일입니다. 스택 오버플로를 입력하면 사용자, 질문 및 답변이 무엇인지, 미디어 유형을 알고 있으며 웹 사이트에서 해당 링크를 제공합니다. REST API는 동일한 작업을 수행해야합니다. 질문과 답변 링크가있는 홈 페이지 대신 사람들이 REST를 수행해야한다고 생각하는 방식으로 웹을 디자인 한 경우 질문을 보려면 URI를 가져와야한다는 정적 문서가 있어야합니다 stackoverflow.com/questions/<id>. id를 Question.id로 바꾸고 브라우저에 붙여 넣습니다. 그것은 말도 안되지만, 많은 사람들이 REST라고 생각합니다.

이 마지막 요점은 충분히 강조 할 수 없습니다. 클라이언트가 문서의 템플릿에서 URI를 작성하고 리소스 표현의 링크를 얻지 못하는 경우 REST가 아닙니다. REST 작성자 인 Roy Fielding은이 블로그 게시물에서 명확하게 설명했습니다. REST API는 하이퍼 텍스트 중심이어야합니다 .

위의 내용을 염두에두고 REST가 XML로 제한되지는 않지만 링크를 위해 일부 형식을 디자인하고 표준화해야하는 다른 형식으로 올바르게 수행 할 수 있음을 알 수 있습니다. 하이퍼 링크는 XML에서는 표준이지만 JSON에서는 아닙니다. HAL 과 같은 JSON에 대한 초안 표준이 있습니다 .

마지막으로 REST는 모든 사람을위한 것이 아니며, 그 증거는 대부분의 사람들이 실수로 REST라고 부르는 HTTP API를 사용하여 문제를 매우 잘 해결하고 그 이상으로 모험하지 않는 방법입니다. REST는 때때로, 특히 처음에는 수행하기가 어렵지만 서버 측에서보다 쉽게 진화하고 변경에 대한 클라이언트의 탄력성으로 인해 시간이 지남에 따라 비용을 지불합니다. 빠르고 쉬운 작업이 필요한 경우 REST를 올바르게 사용하는 데 신경 쓰지 마십시오. 아마 당신이 찾고있는 것이 아닐 것입니다. 몇 년 또는 수십 년 동안 온라인 상태를 유지해야 할 것이 필요한 경우 REST가 적합합니다.

답변

RESTvs SOAP는 묻는 올바른 질문 이 아닙니다 .

REST달리가 SOAP있다 하지 프로토콜.

REST이다 건축 양식 과 디자인 네트워크 기반 소프트웨어 아키텍처는.

REST개념을 자원이라고합니다. 자원의 표현은 상태 비 저장이어야합니다. 일부 매체 유형을 통해 표시됩니다. 미디어 유형의 몇 가지 예는 XML, JSON하고 RDF. 리소스는 구성 요소에 의해 조작됩니다. 구성 요소는 표준 유니폼 인터페이스를 통해 리소스를 요청하고 조작합니다. HTTP의 경우,이 인터페이스는 예를 들어, 표준 HTTP 작전으로 구성 GET, PUT, POST, DELETE.

@ Abdulaziz의 질문은 사실 REST과 HTTP함께 종종 사용 된다는 사실을 밝힙니다. 이는 주로 HTTP의 단순성과 RESTful 원칙에 대한 매우 자연스러운 매핑 때문입니다.

기본 REST 원칙

클라이언트-서버 통신

클라이언트-서버 아키텍쳐는 매우 분리 된 관심사를 가지고 있습니다. RESTful 스타일로 빌드 된 모든 애플리케이션도 원칙적으로 클라이언트 서버 여야합니다.

무국적

서버에 대한 각 클라이언트 요청은 해당 상태가 완전히 표시되어야합니다. 서버는 서버 컨텍스트 또는 서버 세션 상태를 사용하지 않고 클라이언트 요청을 완전히 이해할 수 있어야합니다. 모든 상태는 클라이언트에 유지되어야합니다.

캐시 가능

캐시 제약이 사용될 수 있으며, 따라서 응답 데이터가 캐시 가능 또는 캐시 불가능으로 표시 될 수있다. 캐시 가능으로 표시된 모든 데이터는 동일한 후속 요청에 대한 응답으로 재사용 될 수 있습니다.

균일 한 인터페이스

모든 구성 요소는 단일 통일 인터페이스를 통해 상호 작용해야합니다. 이 구성 요소를 통해 모든 구성 요소 상호 작용이 발생하므로 다른 서비스와의 상호 작용은 매우 간단합니다. 인터페이스는 동일합니다! 이것은 또한 구현 변경이 개별적으로 이루어질 수 있음을 의미합니다. 균일 한 인터페이스가 항상 변경되지 않기 때문에 이러한 변경 사항은 기본 구성 요소 상호 작용에 영향을 미치지 않습니다. 한 가지 단점은 인터페이스에 붙어 있다는 것입니다. 인터페이스를 변경하여 특정 서비스에 최적화를 제공 할 수 있다면 REST가이를 금지하므로 운이 나쁘다. 그러나 밝은면에서 REST는 웹에 최적화되어 있으므로 HTTP를 통한 REST의 놀라운 인기가 있습니다!

위의 개념은 REST의 특성을 정의하고 REST 아키텍처를 웹 서비스와 같은 다른 아키텍처와 차별화합니다. REST 서비스는 웹 서비스이지만 웹 서비스는 반드시 REST 서비스 일 필요는 없습니다.

REST 및 위에서 언급 한 글 머리표 에 대한 자세한 내용은 REST 디자인 원칙에 대한 이 블로그 게시물 을 참조하십시오 .

편집 : 의견을 기반으로 내용을 업데이트

답변

SOAP ( Simple Object Access Protocol ) 및 REST ( Representation State Transfer )는 모두 아름답습니다. 그래서 나는 그들을 비교하지 않습니다. 대신 REST를 선호하고 SOAP을 사용할 때 그림을 묘사하려고합니다.

페이로드 란 무엇입니까?

인터넷을 통해 데이터가 전송 될 때 전송되는 각 장치에는 헤더 정보와 전송되는 실제 데이터가 모두 포함됩니다. 헤더는 패킷의 소스와 대상을 식별하는 반면 실제 데이터는 페이로드라고합니다 . 일반적으로 페이로드는 응용 프로그램 대신 대상 데이터와 대상 시스템에서 수신 한 데이터입니다.

예를 들어 전보 를 보내야하며 전보 비용이 단어에 따라 달라진다는 것을 모두 알고 있습니다.

아래에 언급 된이 두 메시지 중 어느 것이 더 저렴합니까?

<name>Arin</name>

또는

"name": "Arin"

동일한 메시지를 나타내는 두 번째 메시지는 비용면에서 저렴하지만 두 번째 답변이 될 것입니다.

따라서 JSON 형식으로 네트워크를 통해 데이터를 보내는 것이 payload에 관한 XML 형식으로 보내는 것보다 저렴 하다고 말하려고합니다 .

다음은 SOAP보다 REST의 첫 번째 장점 또는 장점입니다 . SOAP는 XML 만 지원하지만 REST는 텍스트, JSON, XML 등과 같은 다른 형식을 지원합니다. Json을 사용하면 페이로드와 관련하여 더 나은 위치에있을 것입니다.

이제 SOAP는 유일한 XML을 지원 하지만 장점도 있습니다.

정말! 어떻게?

SOAP는 메시지의 내용과 처리 방법을 정의하는 3 가지 방식의 Envelope에서 XML을 사용합니다.

데이터 유형에 대한 일련의 인코딩 규칙과 마지막으로 수집 된 프로 시저 호출 및 응답의 레이아웃입니다.

이 봉투는 전송 (HTTP / HTTPS)을 통해 전송되고 RPC (원격 프로 시저 호출)가 실행되고 봉투는 XML 형식의 문서로 정보와 함께 반환됩니다.

중요한 점은 SOAP의 장점 중 하나 는 “일반”전송을 사용 하지만 REST는 HTTP / HTTPS를 사용 한다는 것입니다 . SOAP는 거의 모든 전송을 사용하여 요청을 보낼 수 있지만 REST는 할 수 없습니다. 그래서 우리는 SOAP 사용의 이점을 얻었습니다.

위의 단락에서 이미 언급했듯이 “REST는 HTTP / HTTPS를 사용합니다.” 이 단어들에 대해 조금 더 깊이 살펴보십시오.

REST over HTTP에 대해 이야기 할 때 HTTP를 적용한 모든 보안 조치가 상속되며 이는 전송 레벨 보안 으로 알려져 있으며 유선 내부에있는 동안에 만 메시지를 보호 하지만 일단 다른 쪽에서 전달하면 알 수 없습니다. 데이터가 처리 될 실제 지점에 도달하기 전에 거쳐야하는 단계 수 물론 모든 단계에서 HTTP와 다른 것을 사용할 수 있습니다. 휴식은 완전히 안전하지 않습니까?

그러나 SOAP 는 REST와 마찬가지로 SSL 을 지원하며 일부 엔터프라이즈 보안 기능을 추가 하는 WS-Security도 지원 합니다. WS-Security는 메시지 작성에서 소비 까지 보호합니다 . 따라서 전송 수준 보안을 위해 WS-Security를 사용하여 방지 할 수있는 허점을 발견했습니다.

그 외에도 REST는 HTTP 프로토콜에 의해 제한 되므로 트랜잭션 지원은 ACID와 호환되지 않으며 분산 된 다국적 리소스에서 2 단계 커밋을 제공 할 수 없습니다.

그러나 SOAP는 단기 트랜잭션을 위한 ACID 기반 트랜잭션 관리 와 장기 실행 트랜잭션을위한 보상 기반 트랜잭션 관리를 모두 포괄적으로 지원 합니다. 또한 분산 리소스에서 2 단계 커밋을 지원 합니다 .

결론을 내리지는 않지만 보안, 트랜잭션 등이 주요 관심사 인 반면 SOAP 기반 웹 서비스를 선호합니다.

다음 조건을 만족할 때 RESTful 디자인이 적합 할 수 있다고 말한 “The Java EE 6 Tutorial” 입니다. 보세요

내 대답을 읽는 것이 즐거웠기를 바랍니다.

답변

REST ( RE 표상 S 탓에 T 를 ransfer)
RE 표상 S 탓에 객체의이다 T는 우리가 객체의 상태를 보내, 나머지는 우리가 객체를 전송하지 않습니다 즉이다 ransferred. REST는 건축 스타일입니다. SOAP와 같은 많은 표준을 정의하지는 않습니다. REST는 인터넷에서 공개 API (예 : Facebook API, Google Maps API)를 노출하여 데이터에 대한 CRUD 작업을 처리하기위한 것입니다. REST는 일관된 단일 인터페이스를 통해 명명 된 리소스에 액세스하는 데 중점을 둡니다.

SOAP는 ( S imple O bject CCESS P rotocol)
SOAP 자체 프로토콜을 제공하고 서비스로 애플리케이션 로직 (되지 않은 데이터)의 조각 노출에 초점을 맞추고 있습니다. SOAP는 작업을 노출합니다. SOAP는 명명 된 작업에 액세스하는 데 중점을두고 있으며, 각 작업은 일부 비즈니스 로직을 구현합니다. SOAP는 일반적으로 웹 서비스 라고하지만 이것은 잘못된 이름입니다. SOAP는 웹과 관련이 있으면 거의 없습니다. REST는 URI와 HTTP를 기반으로 진정한 웹 서비스 를 제공합니다 .

왜 REST인가?

REST는 표준 HTTP를 사용하므로 훨씬 간단합니다.
REST는 구현하기 쉽고 대역폭과 리소스가 덜 필요합니다.
REST는 SOAP이 XML 만 허용하는 다양한 데이터 형식을 허용합니다.
REST는 JSON을 지원하므로 브라우저 클라이언트를 더 잘 지원할 수 있습니다.
REST는 성능과 확장 성이 향상되었습니다. REST 읽기를 캐시 할 수 있고 SOAP 기반 읽기를 캐시 할 수 없습니다.
보안이 주요 관심사가 아니며 자원이 제한되어있는 경우. 또는 다른 개발자가 공개적으로 쉽게 사용할 수있는 API를 만들고 싶다면 REST를 사용해야합니다.
Stateless CRUD 작업이 필요한 경우 REST를 사용하십시오.
REST는 일반적으로 소셜 미디어, 웹 채팅, 모바일 서비스 및 Google지도와 같은 공개 API에서 사용됩니다.
같은 요청 헤더 매개 변수 “동의”에 따라 동일한 자원에 대한 RESTful 서비스 리턴 다양한 MediaTypes, application/xml또는 application/jsonPOST 및 /user/1234.json또는 GET /user/1234.xmlGET을 위해.
REST 서비스는 최종 사용자가 아닌 클라이언트 측 애플리케이션에서 호출하도록되어 있습니다.
ST 나머지는에서 온다 S 탓에 T 를 ransfer. 서버가 저장하지 않고 상태를 전송하면 REST 서비스를 확장 할 수 있습니다.

왜 SOAP인가?

SOAP는 구현하기가 쉽지 않으며 더 많은 대역폭과 리소스가 필요합니다.
SOAP 메시지 요청은 REST에 비해 느리게 처리되며 웹 캐싱 메커니즘을 사용하지 않습니다.
WS-Security : SOAP는 REST와 마찬가지로 SSL을 지원하지만 일부 엔터프라이즈 보안 기능을 추가하는 WS-Security도 지원합니다.
WS-AtomicTransaction : 서비스를 통한 ACID 트랜잭션이 필요합니다. SOAP가 필요합니다.
WS-ReliableMessaging : 애플리케이션에 비동기 처리와 보장 된 수준의 안정성 및 보안이 필요한 경우. Rest에는 표준 메시징 시스템이 없으며 클라이언트가 다시 시도하여 통신 실패를 처리 할 것으로 예상합니다.
보안이 주요 관심사이고 자원이 제한되지 않는 경우 SOAP 웹 서비스를 사용해야합니다. 지불 게이트웨이, 금융 및 통신 관련 작업을위한 웹 서비스를 작성하는 것처럼 높은 보안이 필요하므로 SOAP을 사용해야합니다.

소스 1
소스 2

답변

휴식과 비누의 차이

비누

SOAP는 프로토콜입니다.
SOAP는 Simple Object Access Protocol의 약어입니다.
SOAP는 프로토콜이므로 REST를 사용할 수 없습니다.
SOAP는 서비스 인터페이스를 사용하여 비즈니스 로직을 노출합니다.
SOAP는 엄격하게 준수해야 할 표준을 정의합니다.
SOAP에는 REST보다 더 많은 대역폭과 자원이 필요합니다.
SOAP는 자체 보안을 정의합니다.
SOAP는 XML 데이터 형식 만 허용합니다.
SOAP보다 REST가 덜 선호됩니다.

쉬다

REST는 건축 스타일입니다.
REST는 Representational State Transfer를 나타냅니다.
REST는 개념이기 때문에 SOAP 웹 서비스를 사용할 수 있으며 HTTP, SOAP와 같은 프로토콜을 사용할 수 있습니다.
REST는 URI를 사용하여 비즈니스 로직을 노출합니다.
REST는 SOAP와 같은 너무 많은 표준을 정의하지 않습니다.
REST는 SOAP보다 적은 대역폭과 자원이 필요합니다.
RESTful 웹 서비스는 기본 전송에서 보안 조치를 상속합니다.
REST는 일반 텍스트, HTML, XML, JSON 등과 같은 다른 데이터 형식을 허용합니다.
SOAP보다 REST가 더 선호됩니다.

자세한 내용은 여기 를 참조 하십시오

답변

IMHO SOAP와 REST가 서로 다른 두 가지를 비교할 수 없습니다.

SOAP 는 프로토콜이고 REST 는 소프트웨어 아키텍처 패턴입니다. 인터넷 대 SOAP 대 REST에 대한 많은 오해가 있습니다.

SOAP 는 웹 서비스 가능 응용 프로그램이 인터넷을 통해 서로 통신하는 데 사용하는 XML 기반 메시지 형식을 정의합니다. 그러기 위해서는 응용 프로그램이 메시지 계약, 데이터 유형 등에 대한 사전 지식이 필요합니다.

REST 는 URL에서 서버의 상태 (자원)를 나타냅니다. 상태 비 저장 상태이므로 클라이언트는 하이퍼 미디어에 대한 이해를 넘어서는 서버와 상호 작용할 수있는 사전 지식이 없어야합니다.

답변

우선, 공식적으로 올바른 질문은 web services + WSDL + SOAPvs REST입니다.

비록 웹 서비스 가 느슨한 의미로 사용 되기는하지만, HTTP 프로토콜을 사용하여 웹 페이지 대신 데이터 를 전송할 때 공식적 으로는 그 아이디어의 매우 구체적인 형태입니다. 정의에 따르면 REST는 “웹 서비스”가 아닙니다.

그러나 실제로는 모든 사람이이를 무시하므로 무시해도됩니다.

이미 기술적 답변이 있으므로 직관을 제공하려고 노력할 것입니다.

다른 프로그래밍 언어로 구현 된 원격 컴퓨터에서 함수를 호출하려고한다고 가정합니다 (종종 원격 프로 시저 호출 / RPC 라고 함 ). 기능을 작성한 사람이 제공 한 특정 URL에서 기능을 찾을 수 있다고 가정하십시오. 당신은 (어쨌든) 메시지를 보내고 응답을 받아야합니다. 따라서 고려해야 할 두 가지 주요 질문이 있습니다.

보내야 할 메시지의 형식은 무엇입니까
메시지를 어떻게 전달해야합니까

첫 번째 질문의 공식 정의는 WSDL 입니다. 이것은 상세하고 엄격한 형식으로 매개 변수, 유형, 이름, 기본값, 호출 할 함수 이름 등을 설명하는 XML 파일입니다. 여기서 WSDL의 예 는 파일이 사람임을 보여줍니다. -읽기 쉽지만 쉽지는 않습니다.

두 번째 질문에는 다양한 답변이 있습니다. 그러나 실제로 사용되는 유일한 것은 SOAP 입니다. 주요 아이디어는 이전 XML (실제 메시지)을 다른 XML (인코딩 정보 및 기타 유용한 정보 포함)로 랩핑하고 HTTP를 통해 전송하는 것입니다. 항상 body가 있으므로 HTTP의 POST 메소드를 사용하여 메시지를 보냅니다 .

이 전체 접근 방식의 주요 아이디어는 URL을 함수 , 즉 액션에 매핑하는 것입니다 . 따라서 일부 서버에 고객 목록이 있고 고객을 보거나 업데이트 / 삭제하려면 3 개의 URL이 있어야합니다.

myapp/read-customer 메시지 본문에서 읽을 고객의 ID를 전달하십시오.
myapp/update-customer 본문에서 고객의 ID와 새 데이터를 전달합니다.
myapp/delete-customer 그리고 몸의 id

REST 접근법은 사물을 다르게 본다. URL은 작업을 나타내는 것이 아니라 REST 링고에서 resource 라고 하는 것 입니다. HTTP 프로토콜 (이미 사용 중)은 동사를 지원하므로 해당 동사를 사용 하여 사물에 대해 수행 할 작업 을 지정 하십시오.

따라서 REST 접근 방식을 사용하면 고객 번호 12는 URL에서 찾을 수 있습니다 myapp/customers/12. 고객 데이터를 보려면 GET 요청으로 URL을 누르십시오. DELETE 동사가있는 동일한 URL 을 삭제하십시오 . 다시 업데이트하려면 POST 동사 가 포함 된 동일한 URL과 요청 본문의 새 내용을 업데이트하십시오.

진정으로 RESTful 한 것으로 간주하기 위해 서비스가 충족해야하는 요구 사항에 대한 자세한 내용은 Richardson 성숙 모델을 참조하십시오 . 이 기사에서는 예를 제공하고, 소위 SOAP 서비스가 레벨 0 REST 서비스 인 이유를 설명합니다 (레벨 0은이 모델에 대한 낮은 준수를 의미하지만 공격적이지 않으며 여전히 유용합니다) 많은 경우에).