누군가 영어 가 무엇인지 REST 와 SOAP 가 무엇인지 설명 할 수 있습니까 ? 그리고 웹 서비스는 어떻게 작동합니까?

SOAP 및 REST에 대한 간단한 설명

SOAP- "간단한 개체 액세스 프로토콜"

SOAP는 인터넷을 통해 메시지 또는 소량의 정보를 전송하는 방법입니다. SOAP 메시지는 XML 형식이며 일반적으로 HTTP (하이퍼 텍스트 전송 프로토콜)를 사용하여 전송됩니다.

휴식-대표 상태 이전

Rest는 클라이언트와 서버간에 데이터를주고받는 간단한 방법이며 정의 된 표준이 많지 않습니다. JSON, XML 또는 일반 텍스트로 데이터를주고받을 수 있습니다. SOAP에 비해 가볍습니다.

두 방법 모두 많은 대형 플레이어가 사용합니다. 그것은 선호의 문제입니다. 사용하기 쉽고 이해하기 쉽기 때문에 선호합니다.

SOAP (Simple Object Access Protocol) :

• SOAP는 HTTP 또는 때로는 TCP / IP 위에 XML 프로토콜을 빌드합니다.
• SOAP는 기능 및 데이터 유형을 설명합니다.
• SOAP는 XML-RPC의 후속 버전이며 매우 유사하지만 표준 통신 방법을 설명합니다.
• 일부 프로그래밍 언어는 SOAP를 기본적으로 지원하므로 일반적으로 웹 서비스 URL을 제공하며 특정 코드없이 웹 서비스 기능을 호출 할 수 있습니다.
• 전송 된 이진 데이터는 먼저 base64로 인코딩 된 형식으로 인코딩해야합니다.
• WSDL, XSD, SOAP, WS-Addressing과 관련된 몇 가지 프로토콜 및 기술이 있습니다.

REST (Representational State Transfer) :

• REST는 HTTP를 사용할 필요는 없지만 아래의 대부분의 요점은 HTTP 편향입니다.
• REST는 매우 가벼우므로 1 분 정도 기다리면 SOAP에서 생성 한 이러한 복잡성을 모두 필요로하지는 않습니다.
• 일반적으로 모든 것을 설명하는 큰 XML 형식 대신 일반 HTTP 메소드를 사용합니다. 예를 들어 HTTP GET을 사용하는 리소스를 얻으려면 HTTP PUT을 사용하는 서버에 리소스를 넣으십시오. 서버에서 자원을 삭제하려면 HTTP DELETE를 사용하십시오.
• REST는 HTTP GET, POST 및 PUT 메소드를 사용하여 서버의 자원을 업데이트한다는 점에서 매우 간단합니다.
• REST는 일반적으로 ROA ( Resource Oriented Architecture) 와 함께 사용하는 것이 가장 좋습니다 . 이 사고 방식에서는 모든 것이 하나의 리소스이며 이러한 리소스를 사용하게됩니다.
• 프로그래밍 언어에 HTTP 라이브러리가 있고 대부분의 경우 REST HTTP 프로토콜을 매우 쉽게 사용할 수 있습니다.
• 이진 데이터 또는 이진 리소스는 요청에 따라 간단히 제공 할 수 있습니다.

Google의 REST와 SOAP에 대한 끝없는 논쟁 이 있습니다 .

내가 가장 좋아하는 것은 이것 입니다. 2013 년 11 월 27 일 업데이트 : Paul Prescod 사이트가 오프라인 상태 인 것으로 보이며이 기사는 더 이상 사용할 수 없습니다. 사본은 Wayback Machine에서 또는 CiteSeerX 에서 PDF로 볼 수 있습니다 .

쉬다

REST의 주요 아이디어는 매우 간단하다는 것을 알고 있습니다. 우리는 몇 년 동안 웹 브라우저를 사용해 왔으며 웹 사이트가 얼마나 쉽고 유연하며 성능이 좋은지를 보았습니다. HTML 사이트는 하이퍼 링크와 양식을 사용자 상호 작용의 기본 수단으로 사용합니다. 그들의 주요 목표는 고객이 우리 가 현재 상태에서 사용할 수 있는 링크 만 알 수 있도록 하는 것 입니다. REST는 단순히 '애플리케이션을 통해 사람이 아닌 컴퓨터를 구동하기 위해 동일한 원칙을 사용하지 않는 이유는 무엇입니까?' 이것을 WWW 인프라의 강력한 기능과 결합하면 훌륭한 분산 응용 프로그램을 구축하기위한 킬러 도구를 얻게됩니다.

또 다른 가능한 설명은 수학적으로 사람들을 생각하는 것입니다. 각 애플리케이션은 기본적으로 비즈니스 로직 조치가 상태 전이 인 상태 머신입니다. REST의 아이디어는 각 전이를 일부 요청에 자원으로 맵핑하고 현재 상태에서 사용 가능한 전이를 나타내는 링크를 클라이언트에 제공하는 것입니다. 따라서 표현과 링크를 통해 상태 머신을 모델링합니다. 이것이 대표적 상태 이전이라고 불리는 이유입니다.

모든 답변이 메시지 형식이나 HTTP 동사 사용법에 중점을 둔 것 같습니다. 실제로 메시지 형식은 중요하지 않으며 REST는 서비스 개발자가 문서화 한 문서 중 하나를 사용할 수 있습니다. HTTP 동사는 서비스를 CRUD 서비스로만 만들지 만 아직 RESTful하지는 않습니다. 실제로 서비스를 REST 서비스로 바꾸는 것은 데이터와 함께 서버 응답에 포함 된 하이퍼 링크 (일명 하이퍼 미디어 컨트롤)이며, 클라이언트가 해당 링크에서 다음 작업을 선택하기에 충분한 양이어야합니다.

불행히도 Roy Fielding의 논문을 제외하고는 웹에서 REST에 대한 정확한 정보를 찾기가 다소 어렵습니다 . (그는 REST를 파생 한 사람입니다). SOAP에서 REST로 진화하는 방법에 대한 포괄적 인 단계별 자습서를 제공하는 'REST in Practice'책 을 추천합니다 .

비누

이것은 RPC (원격 프로 시저 호출) 아키텍처 스타일의 가능한 형식 중 하나입니다. 본질적으로 클라이언트가 서비스 경계 (네트워크, 프로세스 등)를 통해 로컬 메소드를 호출하는 것처럼 서버의 메소드를 호출 할 수있게하는 기술 일뿐입니다. 물론 속도, 신뢰성 등에서 로컬 메소드를 호출하는 것과 실제로는 다르지만 아이디어는 간단합니다.

비교

전송 프로토콜, 메시지 형식, xsd, wsdl 등과 같은 세부 사항은 RPC의 형태를 REST와 비교할 때 중요하지 않습니다. 가장 큰 차이점은 RPC 서비스는 RPC API에서 자신 만의 응용 프로그램 프로토콜을 알고있는 시맨틱으로 설계하여 자전거를 재창조한다는 것입니다. 따라서 모든 클라이언트는 서비스를 사용하기 전에이 프로토콜을 이해해야하며 모든 요청의 독점적 의미로 인해 캐시와 같은 일반 인프라를 구축 할 수 없습니다. 또한 RPC API는 현재 상태에서 허용되는 작업을 제안하지 않으며 추가 설명서에서 파생되어야합니다. 반면에 REST는 다양한 클라이언트가 API 의미를 이해하고 하이퍼 미디어 컨트롤 (링크)을 통해 각 상태에서 사용 가능한 옵션을 강조 할 수 있도록 균일 한 인터페이스를 사용함을 의미합니다. 그러므로,

어떤 식 으로든 SOAP (다른 RPC와 마찬가지로)는 연결 미디어를 메시지 만 전송할 수있는 블랙 박스로 취급하는 서비스 경계를 ​​통해 터널링하려는 시도입니다. REST는 웹이 거대한 분산 정보 시스템임을 인정하고 세상을있는 ​​그대로 받아들이고 웹을 대항하는 대신 마스터하는 법을 배우는 결정입니다.

SOAP는 서버와 클라이언트를 모두 제어하고 상호 작용이 너무 복잡하지 않은 경우 내부 네트워크 API에 적합합니다. 개발자가 사용하는 것이 더 자연 스럽습니다. 그러나 많은 독립 당사자가 사용하는 공용 API가 복잡하고 크면 REST가 더 적합해야합니다. 그러나이 마지막 비교는 매우 모호합니다.

최신 정보

내 경험상 예기치 않게 REST 개발이 SOAP보다 어렵다는 것을 보여주었습니다. 적어도 .NET의 경우. ASP.NET Web API와 같은 훌륭한 프레임 워크가 있지만 클라이언트 측 프록시를 자동으로 생성하는 툴링은 없습니다. '웹 서비스 참조 추가'또는 'WCF 서비스 참조 추가'와 같은 것은 없습니다. 모든 직렬화 및 서비스 쿼리 코드를 직접 작성해야합니다. 그리고 사람, 그것은 많은 상용구 코드입니다. REST 개발에는 각 개발 플랫폼마다 WSDL 및 툴링 구현과 유사한 것이 필요하다고 생각합니다. 실제로 WADL 또는 WSDL 2.0 과 같은 좋은 근거가 있지만 표준 중 어느 것도 잘 지원되지 않는 것 같습니다.

업데이트 (2016 년 1 월)

이제 REST API 정의를위한 다양한 도구 가 있습니다. 나의 개인적 취향은 현재 RAML 입니다.

웹 서비스 작동 방식

글쎄, 이것은 특정 웹 서비스에 사용되는 아키텍처와 기술에 의존하기 때문에 너무 광범위한 질문입니다. 그러나 일반적으로 웹 서비스는 클라이언트의 요청을 수락하고 응답을 반환 할 수있는 웹의 일부 응용 프로그램입니다. 그것은 웹에 노출되어 있으므로 웹 서비스이므로 일반적으로 연중 무휴로 제공 되므로 서비스 입니다. 물론 클라이언트의 일부 문제 (그렇지 않으면 누군가가 웹 서비스를 사용하는 이유)를 해결합니다.

이것은 당신이 찾게 될 가장 간단한 설명입니다.

이 기사는 남편을 아내 이야기로 가져 가고 남편은 아내에게 REST에 대해 순수한 평신도 용어로 설명합니다. 읽어야합니다!

How-i-explained-rest-to-my-wife (원본 링크)
how-i-explained-rest-to-my-wife (2013-07-19 워킹 링크)

SOAP-Simple Object Access Protocol 은 프로토콜입니다 !

REST-Representational State Transfer 는 아키텍처 스타일입니다 !

SOAP 일반적으로 HTTP를 통해 메시지를 전송하는 데 사용되는 XML 프로토콜입니다.

REST하고 SOAP있습니다 틀림 없습니다 상호 배타적. 편안한 아키텍처를 사용할 수 있습니다 HTTP또는 SOAP다른 통신 프로토콜 또는. REST웹에 최적화되어 있으므로 HTTP완벽한 선택입니다. Roy Fielding의 논문에서 논의 된 유일한 프로토콜 HTTP이기도합니다 .

REST와 SOAP은 분명히 매우 다르지만, 문제는 사실 조명 않습니다 REST및 HTTP자주 직렬로 사용됩니다. 이는 주로 HTTP의 단순성과 RESTful 원칙에 대한 매우 자연스러운 매핑 때문입니다.

기본 REST 원칙

클라이언트-서버 통신

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

무국적

서버에 대한 각 클라이언트 요청마다 해당 상태가 완전히 표시되어야합니다. 서버는 서버 컨텍스트 또는 서버 세션 상태를 사용하지 않고 클라이언트 요청을 완전히 이해할 수 있어야합니다. 모든 상태는 클라이언트에 유지되어야합니다. 상태 비 저장 표현에 대해서는 나중에 자세히 설명하겠습니다.

캐시 가능

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

균일 한 인터페이스

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

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

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

Brian R. Bondy의 답변이 마음에 듭니다. Wikipedia가 REST에 대한 명확한 설명을 제공한다고 덧붙였습니다 . 이 기사는 SOAP과 구별됩니다.

REST는 가능한 한 간단하게 수행되는 상태 정보 교환입니다.

SOAP는 XML을 사용하는 메시지 프로토콜입니다.

많은 사람들이 SOAP에서 REST로 이동 한 주요 이유 중 하나는 SOAP 기반 웹 서비스와 관련된 WS-* (WS splat) 표준이 매우 복잡하기 때문입니다. 사양 목록은 wikipedia 를 참조하십시오 . 이러한 각 사양은 매우 복잡합니다.

편집 : 어떤 이유로 링크가 올바르게 표시되지 않습니다. REST = http://en.wikipedia.org/wiki/REST

WS- * = http://en.wikipedia.org/wiki/WS- *

SOAP 웹 서비스와 REST 웹 서비스는 모두 HTTP 프로토콜 및 기타 프로토콜을 사용할 수 있습니다 (SOAP는 REST의 기본 프로토콜 일 수 있습니다). HTTP 프로토콜 관련 SOAP 및 REST에 대해서만 이야기하겠습니다. 가장 자주 사용되기 때문입니다.

비누

SOAP ( "간단한"개체 액세스 프로토콜)는 프로토콜 (및 W3C 표준 )입니다. SOAP 메시지를 작성, 전송 및 처리하는 방법을 정의합니다.

• SOAP 메시지는 특정 구조의 XML 문서입니다. 헤더와 본문 섹션이 포함 된 봉투가 들어 있습니다. 본문에는 XML 형식으로 전송하려는 실제 데이터가 포함되어 있습니다. 인코딩 스타일 에는 두 가지가 있지만 일반적으로 literal을 선택합니다. 즉, 응용 프로그램 또는 해당 SOAP 드라이버가 데이터의 직렬화 및 직렬화 해제를 수행합니다.

• SOAP 메시지는 SOAP + XML MIME 하위 유형이있는 HTTP 메시지로 이동합니다. 이러한 HTTP 메시지는 여러 부분으로 구성 될 수 있으므로 선택적으로 SOAP 메시지에 파일을 첨부 할 수 있습니다.

• 분명히 우리는 클라이언트-서버 아키텍처를 사용하므로 SOAP 클라이언트는 SOAP webserices에 요청을 보내고 서비스는 클라이언트에 응답을 다시 보냅니다. 대부분의 웹 서비스는 WSDL 파일을 사용하여 서비스를 설명합니다. WSDL 파일에는 보내려는 데이터의 XML 스키마 (이하 XSD)와 웹 서비스가 HTTP 프로토콜에 바인딩되는 방법을 정의하는 WSDL 바인딩이 포함됩니다. 거기 두 바인딩 스타일: RPC 및 문서. RPC 스타일 바인딩에 의해 SOAP 본문에는 매개 변수 (HTTP 요청) 또는 리턴 값 (HTTP 응답)을 사용한 조작 호출 표현이 포함됩니다. 매개 변수 및 리턴 값은 XSD에 대해 유효성 검증됩니다. 문서 스타일 바인딩에 의해 SOAP 본문에는 XSD에 대해 유효성이 검증 된 XML 문서가 포함됩니다. 문서 바인딩 스타일이 이벤트 기반 시스템에 더 적합하다고 생각하지만 해당 바인딩 스타일을 사용한 적이 없습니다. RPC 바인딩 스타일이 더 널리 사용되므로 대부분의 사람들은 분산 응용 프로그램에서 XML / RPC 목적으로 SOAP를 사용합니다. 웹 서비스는 일반적으로 UDDI 서버 에 요청하여 서로를 찾습니다 . UDDI 서버는 웹 서비스의 위치를 ​​저장하는 레지스트리입니다.

SOAP RPC

내 의견으로는 가장 널리 사용되는 SOAP 웹 서비스는 RPC 바인딩 스타일과 리터럴 인코딩 스타일을 사용하며 다음과 같은 속성이 있습니다.

• URL을 오퍼레이션에 맵핑합니다.
• SOAP + XML MIME 하위 유형으로 메시지를 보냅니다.
• 서버 측 세션 저장소를 가질 수 있으며 이에 대한 제한은 없습니다.
• SOAP 클라이언트 드라이버는 서비스의 WSDL 파일을 사용하여 RPC 조작을 메소드로 변환합니다. 클라이언트 측 애플리케이션은 이러한 메소드를 호출하여 SOAP 웹 서비스와 통신합니다. 따라서 대부분의 SOAP 클라이언트는 인터페이스 변경 (결과 메소드 이름 및 / 또는 매개 변수 변경)에 의해 중단됩니다.
• RDF를 사용하여 인터페이스 변경으로 인해 깨지지 않고 시맨틱으로 작업을 찾는 SOAP 클라이언트를 작성할 수는 있지만 시맨틱 웹 서비스 는 매우 드물며 반드시 브레이킹되지 않는 클라이언트를 가질 필요는 없습니다.

쉬다

REST (Representational State Transfer)는 Roy Fielding 논문 에 설명 된 아키텍처 스타일입니다 . SOAP처럼 프로토콜에 대해서는 신경 쓰지 않습니다. 제약 조건이없는 null 아키텍처 스타일로 시작하고 REST 아키텍처의 제약 조건을 하나씩 정의합니다. 사람들은 모든 REST 제약 조건을 충족시키는 웹 서비스에 RESTful이라는 용어를 사용하지만 Roy Fielding에 따르면 REST 레벨 과 같은 것은 없습니다 . 웹 서비스가 모든 단일 REST 제약 조건을 충족하지 않는 경우 REST 웹 서비스가 아닙니다.

REST 제약

• 클라이언트-서버 아키텍처-이 부분은 모든 사람에게 친숙하다고 생각합니다. REST 클라이언트는 REST 웹 서비스와 통신하고, 웹 서비스는 공통 데이터 (이후 자원 상태)를 유지하고이를 클라이언트에 제공합니다.
• Stateless-약어의 "상태 이전"부분 : REST. 클라이언트는 클라이언트 상태 (세션 / 애플리케이션 상태)를 유지하므로 서비스에 세션 스토리지가 없어야합니다. 클라이언트는 모든 요청에 ​​의해 클라이언트 상태의 관련 부분을 자원 상태의 관련 부분 (관리자가 유지)으로 응답하는 서비스로 전송합니다. 따라서 요청에는 컨텍스트가 없으며 요청을 처리하는 데 필요한 정보가 항상 포함되어 있습니다. 예를 들어 HTTP 기본 인증을 통해 사용자 이름과 비밀번호는 클라이언트에 의해 저장되며 모든 요청과 함께 전송되므로 모든 요청에서 인증이 수행됩니다. 이는 로그인으로 만 인증이 수행되는 일반 웹 응용 프로그램과는 매우 다릅니다. 메모리 내 (javascript), 쿠키, localStorage 등과 같은 클라이언트 측 데이터 저장 메커니즘을 사용할 수 있습니다. 원하는 경우 클라이언트 상태의 일부를 유지합니다. 상태 비 저장 제한 조건의 이유는 모든 단일 클라이언트의 세션을 유지할 필요가 없을 때 서버가 매우 높은로드 (수백만 명의 사용자)에 의해 확장 될 수 있다는 것입니다.
• 캐시-응답에는 클라이언트가 캐시 할 수 있는지 여부에 대한 정보가 포함되어야합니다. 이것은 확장 성을 더욱 향상시킵니다.

• 균일 한 인터페이스

  • 자원 식별-REST 자원은 RDF 자원 과 동일 합니다. Fielding에 따르면 이름을 지정할 수있는 경우 자원 일 수 있습니다. 예를 들어 "현재 지역 날씨"는 자원 일 수 있거나 "휴대 전화"는 자원 일 수 있습니다. "특정 웹 문서"는 자원. 리소스를 식별하기 위해 URL 및 URN (예 : ISBN by books by books ) 과 같은 리소스 식별자를 사용할 수 있습니다 . 단일 식별자는 특정 리소스에만 속해야하지만 단일 리소스에는 많은 식별자가있을 수 있습니다. 이러한 식별자는 예를 들어와 같은 URL로 페이지 매김을 통해 악용됩니다 https://example.com/api/v1/users?offset=50&count=25. URL에는 몇 가지 사양이 있습니다예를 들어 경로는 동일하지만 쿼리가 다른 URL이 동일하지 않거나 경로 부분에 URL의 계층 데이터가 포함되어야하고 쿼리 부분에 비 계층 데이터가 포함되어야합니다. REST로 URL을 작성하는 방법의 기본 사항입니다. Btw. URL 구조는 서비스 개발자에게만 중요하며 실제 REST 클라이언트는 관련이 없습니다. 또 다른 자주 묻는 질문은 API 버전 관리입니다. 이는 Fielding에 따르면 자원에 의한 유일한 상수는 의미론이기 때문에 쉬운 것입니다. 의미가 변경되면 새 버전 번호를 추가 할 수 있습니다. 클래식 3 숫자 버전 을 사용하고 URL에 주요 숫자 만 추가 할 수 있습니다 (https://example.com/api/v1/). 따라서 이전 버전과 호환되는 변경 사항이 발생하지 않으면 이전 버전과 호환되지 않는 변경 사항으로 인해 새로운 API root를 사용하여 이전 버전과 호환되지 않는 의미가 https://example.com/api/v2/있습니다. 따라서 오래된 클라이언트는 https://example.com/api/v1/오래된 의미와 함께 사용할 수 있기 때문에 중단되지 않습니다 .
  • 표현을 통한 자원 조작-HTTP 메소드 및 자원 ID와 함께 자원의 의도 된 표현을 REST 서비스로 보내 자원과 관련된 데이터 (자원 상태)를 조작 할 수 있습니다. 예를 들어 결혼 후 사용자 이름을 바꾸려면 응답을 보낼 수 있습니다 . 따라서이 표현을 사용하여 클라이언트 상태를 변경할 수 있습니다. 예를 들어 "Smith Smith 페이지에 오신 것을 환영합니다!" 메시지. 리소스는 리소스 식별자 (URL) 또는 요청과 함께 보낸 헤더 에 따라 많은 표현을 가질 수 있습니다 . 예를 들어 Smith 부인 (아마도 누드가 아님)의 이미지를 보낼 수 있습니다.PATCH https://example.com/api/v1/users/1 {name: "Mrs Smith"}{name: "Mrs Smith"} 의도 한 리소스 상태의 JSON 표현, 즉 새 이름 인 요청을 . 이것은 반대로 발생하며, 서비스는 상태를 변경하기 위해 클라이언트에 리소스 표현을 보냅니다. 예를 들어, 새 이름을 읽으려면 GET https://example.com/api/v1/users/1?fields="name"검색 요청을 보내면200 ok, {name: "Mrs Smith"}acceptimage/jpeg 요청한 .
  • 자체 설명 메시지-메시지에는 메시지 처리 방법에 대한 정보가 포함되어야합니다. 예를 들어, URI 및 HTTP 메소드, 컨텐츠 유형 헤더, 캐시 헤더, 데이터의 의미를 설명하는 RDF 등. 표준 메소드를 사용하는 것이 중요합니다. HTTP 메소드 의 스펙 을 아는 것이 중요 합니다. 예를 들어 GET은 요청 URL에 의해 식별 된 정보를 검색하는 것을 의미하고, DELETE는 서버에 주어진 URL에 의해 식별 된 자원을 삭제하도록 요청하는 것을 의미합니다. HTTP 상태 코드도 사양 을가집니다. 새 자원이 작성되었습니다. 404는 요청 된 자원을 서버에서 찾을 수 없음을 의미합니다. 기존 표준을 사용하는 것이 REST의 중요한 부분입니다.

  • 응용 프로그램 상태 엔진 인 하이퍼 미디어 (이하 HATEOAS)-하이퍼 미디어는 하이퍼 링크를 포함 할 수있는 미디어 유형입니다. 웹에서는 URL을 주소 표시 줄에 입력하는 대신 하이퍼 미디어 형식 (일반적으로 HTML)으로 설명 된 링크를 따라 목표를 달성합니다. REST는 동일한 개념을 따르며 서비스에서 보낸 표현에는 하이퍼 링크가 포함될 수 있습니다. 이러한 하이퍼 링크를 사용하여 요청을 서비스에 보냅니다. 응답으로 우리는 새로운 클라이언트 상태를 구축하는 데 사용할 수있는 데이터 (그리고 아마도 더 많은 링크)를 얻습니다. 그래서 하이퍼 미디어는 애플리케이션 상태 (클라이언트 상태)의 엔진입니다. 클라이언트가 하이퍼 링크를 인식하고 따르는 방법이 궁금하십니까? 인간은 매우 간단합니다. 링크 제목을 읽고 입력 필드를 채운 다음 한 번의 클릭만으로도 가능합니다.JSON-LD 와 히드라 ) 또는 실시 예에 대한 하이퍼 특정 용액 (과 IANA 연결 관계 및 벤더 고유의 MIME 타입 에 의해 HAL JSON + ). 많은 기계가 읽을 수있는 XML 및 JSON 하이퍼 미디어 형식이 있으며 그 목록은 다음과 같습니다.

    • XHTML
    • 원자 + XML
    • RDF + XML
    • HAL + XML
    • HAL + JSON
    • JSON-LD
    • RDF + JSON
    • 사이렌
    • 컬렉션 + JSON

    때로는 선택하기가 어렵습니다 ...

• 계층화 된 시스템-클라이언트와 서비스간에 여러 계층을 사용할 수 있습니다. 그들 중 누구도 바로 옆에있는 레이어 외에이 모든 추가 레이어에 대해 알아야합니다. 이러한 계층은 캐시 및로드 밸런싱을 적용하여 확장 성을 향상 시키거나 보안 정책을 시행 할 수 있습니다.
• 주문형 코드-자바 스크립트 코드와 같은 클라이언트의 기능을 브라우저로 확장하는 코드를 되돌릴 수 있습니다. 이것이 REST의 유일한 선택적 제한 조건입니다.

REST 웹 서비스-SOAP RPC 웹 서비스 차이점

따라서 REST 웹 서비스는 SOAP 웹 서비스와 매우 다릅니다 (RPC 바인딩 스타일 및 리터럴 인코딩 스타일 사용)

• 균일 한 인터페이스 (프로토콜의 내부)를 정의합니다.
• URL을 리소스가 아닌 작업에 매핑합니다.
• SOAP + XML 대신 MIME 형식으로 메시지를 보냅니다.
• 상태 비 저장 통신이 있으므로 서버 측 세션 스토리지를 가질 수 없습니다. (SOAP에는 이것에 대한 제약이 없습니다)
• 하이퍼 미디어를 제공하고 클라이언트는 해당 하이퍼 미디어에 포함 된 링크를 사용하여 서비스를 요청합니다. SOAP RPC는 WSDL 파일에 설명 된 조작 바인딩을 사용합니다.
• 시맨틱 변경만으로 URL을 변경하지 않습니다. RDF 시맨틱을 사용하지 않는 SOAP RPC 클라이언트는 WSDL 파일 변경으로 인해 중단됩니다.
• 상태 비 저장 동작으로 인해 SOAP 웹 서비스보다 확장 성이 뛰어납니다.

등등...

SOAP RPC 웹 서비스가 모든 REST 제한 조건을 충족하지는 않습니다.

• 클라이언트-서버 아키텍처-항상
• 무국적- 가능
• 캐시- 가능
• 균일 한 인터페이스-절대
• 계층화 된 시스템- 결코
• 주문형 코드 (선택 사항)-가능

두 번째 질문 인 웹 서비스 란 무엇입니까? 명백한 이유 때문입니다.

WebServices는 본질적으로 특정 기능이나 데이터를 노출하는 논리 (메소드로 불릴 수있는 메서드)입니다. 구현 (기술적으로 말하면 소비 는 단어입니다)을 구현하는 클라이언트 는 메소드 가 받아 들일 매개 변수 와 반환 할 데이터 유형 을 알고 있어야합니다 .

다음 링크 는 REST & SOAP 에 대해 매우 명쾌하게 설명합니다.

REST 대 SOAP

언제 무엇을 선택해야하는지 알고 싶다면 (REST 또는 SOAP), 더 많은 이유를 살펴보십시오!

SOAP와 REST는 서로 다른 시스템이 서로 통신하는 방법을 나타냅니다.

REST는 브라우저가 웹 서버와 통신하는 것과 유사한 기술을 사용하여이를 수행합니다. GET을 사용하여 웹 페이지 요청, 양식 필드에 POST 등

SOAP는 비슷한 것을 제공하지만 XML 블록을 앞뒤로 전송하여 모든 것을 수행합니다. SOAP의 또 다른 주요 구성 요소는 지원되는 기능 및 데이터 요소를 설명하는 XML 문서 인 WSDL입니다. WSDL은 프로그래밍 코드 스텁을 생성 할뿐만 아니라 지원되는 기능을 프로그래밍 방식으로 "발견"하는 데 사용할 수 있습니다.

나는 이것이 내가 설명 할 수있는 것처럼 쉽다고 생각한다. 제발, 누구든지 나를 정정하거나 이것에 추가 할 수 있습니다.

SOAP는 인터넷과 같은 연결이 끊긴 시스템에서 정보 / 데이터를 교환하는 데 사용하는 메시지 형식입니다. XML 메시지를주고받습니다.

웹 서비스는 SOAP 메시지를 전송 또는 수신합니다. 어떤 언어로 작성되었는지에 따라 다르게 작동합니다.

SOAP의 문제점은 HTTP 스택의 이상과 충돌한다는 것입니다. 모든 미들웨어는 요청 또는 응답의 컨텐츠를 이해하지 않고 HTTP 요청에 대해 작업 할 수 있어야하지만, 예를 들어 일반 HTTP 캐싱 서버는 SOAP 컨텐츠의 어느 부분이 캐싱에 중요한지를 모르면 SOAP 요청에 대해 작동하지 않습니다. SOAP는 단지 프록시처럼 자체 통신 프로토콜의 래퍼로 HTTP를 사용합니다.

REST는 네트워크 애플리케이션을 설계하기위한 아키텍처 스타일입니다. 아이디어는 CORBA, RPC 또는 SOAP와 같은 복잡한 메커니즘을 사용하여 시스템간에 연결하는 대신 간단한 HTTP를 사용하여 시스템간에 호출하는 것입니다.

SOAP – "간단한 개체 액세스 프로토콜"

SOAP 는 인터넷을 통한 약간의 메시지 전송 또는 적은 양의 정보입니다. SOAP 메시지는 XML 로 형식화 되며 일반적으로 HTTP를 제어하여 전송됩니다 .

REST – "대표 상태 이전"

REST 는 궁극적 인 결과로 팬과 서버간에 정보를 수신하는 기본적인 절차이며 명백히 많은 표준이 정의되어 있지 않습니다. JSON , XML 또는 일반 텍스트 로 정보를 보내고받을 수 있습니다 . SOAP에 비해 가볍습니다 .

SOAP 기반 웹 서비스 간단히 말해서, SOAP 기반 서비스 모델은 세상을 서로를 통제 할 수는 없지만 공개 된 계약을 존중하여 함께 일해야하는 동등한 동료 생태계로 간주합니다. 지저분한 현실 세계의 유효한 모델이며 메타 데이터 기반 계약은 SOAP 서비스 인터페이스를 형성합니다.

SOAP을 XML 기반 원격 프로 시저 호출과 연결할 수는 있지만 SOAP 기반 웹 서비스 기술은 유연하고 강력한 메시징 모델로 등장했습니다.

SOAP는 모든 시스템이 독립적이며 다른 시스템과 내부 기능의 내부에 대한 지식이있는 시스템이 없다고 가정합니다. 그러한 시스템이 할 수있는 가장 일은 서로에게 메시지를 보내고 그들이 행동하기를 희망하는 것입니다. 시스템은 계약을 이행하기 위해 계약을 게시하고 다른 시스템은 이러한 계약에 의존하여 메시지를 교환합니다.

시스템 간의 계약을 통칭하여 메타 데이터라고하며 서비스 설명, 지원되는 메시지 교환 패턴 및 서비스 품질을 관리하는 정책 (서비스를 암호화하고 안정적으로 제공해야 할 수 있음 등)으로 구성됩니다. 시스템에서 보내고받을 데이터 (메시지 문서)의 사양. 문서는 XML 스키마 정의와 같은 XML 설명 언어를 사용하여 설명됩니다. 모든 시스템이 공개 된 계약을 준수하는 한 상호 운영 될 수 있으며 시스템 내부의 변경 사항은 다른 시스템에 영향을 미치지 않습니다. 모든 시스템은 자체 내부 구현을 계약과주고받을 책임이 있습니다.

REST-대표 상태 전송. 물리적 프로토콜은 HTTP입니다. 기본적으로 REST는 웹에서 URL로 고유하게 식별 할 수있는 모든 고유 자원입니다. 이러한 리소스에서 수행 할 수있는 모든 작업은 HTTP 동사에 매핑되는 제한된 동사 집합 ( "CRUD"동사)으로 설명 할 수 있습니다.

REST는 SOAP보다 훨씬 덜 무겁습니다.

웹 서비스 작업