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 제한 조건을 충족하지는 않습니다.

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