REST 및 SOAP 웹 서비스를 비교하고 대조합니까?

REST 및 SOAP 웹 서비스를 비교하고 대조합니까?

---

이 질문에 이미 답변이 있습니다.

• REST (Representational State Transfer) 및 SOAP (Simple Object Access Protocol) 14 답변

나는 현재 유사한 것이 인터넷 프로토콜 (HTTP)을 사용하여 소비자와 공급자간에 데이터를 교환하는 것임을 알아 냈습니다.

차이점은 다음과 같습니다.

1. SOAP는 XML 기반 메시지 프로토콜이고 REST는 아키텍처 스타일입니다.
2. SOAP는 소비자와 공급자 간의 통신을 위해 WSDL을 사용하는 반면 REST는 XML 또는 JSON을 사용하여 데이터를 보내고받습니다.
3. SOAP는 RPC 메소드를 호출하여 서비스를 호출하고 REST는 단순히 URL 경로를 통해 서비스를 호출합니다.
4. SOAP는 사람이 읽을 수있는 결과를 반환하지 않지만 REST 결과는 일반 XML 또는 JSON으로 읽을 수 있습니다.
5. SOAP는 HTTP뿐만 아니라 SMTP, FTP 등과 같은 다른 프로토콜도 사용하며 REST는 HTTP 만 사용합니다.

그것이 내가 그들 사이의 차이점으로 아는 모든 것입니다. 누구든지 나를 수정하고 더 추가 할 수 있습니다.

---

SOAP는 통신 btw 소비자 및 공급자에 WSDL을 사용하는 반면 REST는 XML 또는 JSON을 사용하여 데이터를 보내고받습니다.

WSDL은 클라이언트와 서비스 간의 계약을 정의하며 본질적으로 정적입니다. REST 계약의 경우 다소 복잡하고 HTTP, URI, Media Formats 및 Application Specific Coordination Protocol에 의해 정의됩니다. WSDL과 달리 매우 동적입니다.

SOAP는 사람이 읽을 수있는 결과를 반환하지 않지만 REST 결과는 일반 XML 또는 JSON으로 읽을 수 있습니다.

이것은 사실이 아닙니다. 일반 XML 또는 JSON은 전혀 RESTful이 아닙니다. 그들 중 어느 것도 메시지가 자체적으로 포함되어야하고 에이전트 / 클라이언트와 서비스 간의 상호 작용을 조정하는 한 REST에 반대되는 제어 (예 : 링크 및 링크 관계, 메서드 정보, 인코딩 정보 등)를 정의하지 않습니다.

링크 + 시맨틱 링크 관계를 통해 클라이언트는 다음 상호 작용 단계가 무엇인지 결정하고 이러한 링크를 따라 가며 서비스와의 통신을 계속할 수 있어야합니다.

메시지가 사람이 읽을 수 있어야 할 필요는 없으며 암호화 형식을 사용하고 완벽하게 유효한 REST 애플리케이션을 구축 할 수 있습니다. 메시지가 사람이 읽을 수 있는지 여부는 중요하지 않습니다.

따라서 일반 XML (application / xml) 또는 JSON (application / json)은 REST 애플리케이션을 빌드하는 데 충분한 형식이 아닙니다. 강력한 의미 론적 의미를 갖고 클라이언트와 서버 간의 상호 작용을 조정하는 데 충분한 제어 정보 (링크 등)를 제공하는 이러한 일반 미디어 유형의 하위 집합을 사용하는 것이 항상 합리적입니다.

• 제어 정보에 대한 자세한 내용은 http://www.amundsen.com/hypermedia/hfactor/ 를 읽어 보는 것이 좋습니다 .
• 웹 링크 : http://tools.ietf.org/html/rfc5988
• 등록 된 링크 관계 : http://www.iana.org/assignments/link-relations/link-relations.xml

REST는 HTTP 만 사용합니다.

사실이 아니라 HTTP가 가장 널리 사용되며 REST 웹 서비스에 대해 이야기 할 때 HTTP를 가정합니다. HTTP는 자체 메소드 (GET, POST, PUT, DELETE, PATCH 등)와 자원과의 상호 작용을 위해 균일하게 사용할 수있는 다양한 헤더로 인터페이스를 정의합니다. 이 균일 성은 다른 프로토콜에서도 달성 할 수 있습니다.

PS REST에 대한 매우 간단하지만 흥미로운 설명 : http://www.looah.com/source/view/2284

---

일상적인 실용적인 프로그래밍 용어에서 가장 큰 차이점은 SOAP를 사용하면 정적 및 강력하게 정의 된 데이터 교환 형식으로 작업하고 REST 및 JSON 데이터 교환 형식이 비교적 느슨하다는 것입니다. 예를 들어 SOAP를 사용하면 교환 된 데이터가 XSD 스키마와 일치하는지 확인할 수 있습니다. 따라서 XSD는 클라이언트와 서버가 교환되는 데이터가 어떻게 구조화되어야하는지 이해하는 방법에 대한 '계약'역할을합니다.

JSON 데이터는 일반적으로 강력하게 정의 된 형식에 따라 전달 되지 않습니다 (예 : http://msdn.microsoft.com/en-us/library/jj870778.aspx 또는 json- 구현 을 지원하는 프레임 워크를 사용하지 않는 한). 개요).

실제로 일부 (대부분 / 대부분)는 JSON의 "동적"비밀 소스가 데이터 계약으로 제한하는 철학 / 문화에 위배된다고 주장합니다 ( JSON RESTful 웹 서비스가 데이터 계약을 사용해야하는 경우 ).

동적으로 느슨하게 입력 된 언어로 작업하는 데 익숙한 사람들은 JSON의 느슨 함을 더 편안하게 느끼는 반면 강력한 유형의 언어를 사용하는 개발자는 XML을 선호합니다.

http://www.mnot.net/blog/2012/04/13/json_or_xml_just_decide

---

SOAP는 자체 프로토콜을 제공하며 데이터가 아닌 애플리케이션 로직을 서비스로 노출하는 데 중점을 둡니다. SOAP는 작업을 노출합니다. SOAP는 명명 된 작업에 액세스하는 데 중점을두고 있으며 각 작업은 서로 다른 인터페이스를 통해 일부 비즈니스 논리를 구현합니다.

SOAP는 일반적으로 "웹 서비스"라고하지만 이것은 잘못된 이름입니다. SOAP는 웹과 관련된 것이 거의 없습니다. REST는 URI 및 HTTP를 기반으로 진정한 "웹 서비스"를 제공합니다.

예를 들어 여기에는 몇 가지 전화와 해설이있는 적절한 집이 있습니다.

getUser(User);

이것은 리소스 (데이터)에 액세스 할 때의 나머지 작업입니다.

switchCategory(User, OldCategory, NewCategory)

REST는 SOAP가 XML 만 허용하는 다양한 데이터 형식을 허용합니다. 여러 형식을 처리해야하기 때문에 REST에 복잡성이 추가되는 것처럼 보일 수 있지만, 제 경험상 실제로는 상당히 유익했습니다. JSON은 일반적으로 데이터에 더 적합하며 훨씬 빠르게 구문 분석됩니다. REST는 JSON 지원으로 인해 브라우저 클라이언트를 더 잘 지원합니다.

참고 URL : https://stackoverflow.com/questions/10975863/compare-and-contrast-rest-and-soap-web-services