SOAP의 현재의 중요성

마지막으로 2013 년 금융 회사에서 인턴쉽을하면서 SOAP 기반 서비스를 접하게되었습니다. 그 때가 IT에서 경력을 쌓기 시작한시기였습니다. 엔지니어링 과정 중 하나에서 SOAP에 대한 학습 자료를 가지고있는 것을 기억합니다. 그 외에도, 나는 경력 동안 SOAP을 많이 사용하지 않았습니다.

"SOAP와 REST의 차이점"이라는 질문이 최근의 인터뷰 중 하나에서 나온 이후로 이것을 묻습니다. 내가 아는 것 (그리고 Google에서 찾은 것)에서 SOAP는 비즈니스 로직과 밀접한 관련이있는 정보 교환을 위해 클라이언트와 서버 사이의 긴밀한 연결을 가진 프로토콜입니다. REST는 데이터 전송을위한보다 유연한 상태 비 저장 아키텍처입니다.

SOAP와 REST의 차이점에 대해 내가 틀렸다면 누군가 나를 수정 해 줄 수 있습니까? 또한 현재 SOAP의 중요성은 무엇입니까? 사람들이 여전히 새로운 SOAP 기반 API를 개발하고 있습니까, 아니면 지금은 대부분 레거시입니까?

REST는 실제로 건축 스타일입니다. SOAP는 데이터 프로토콜입니다. 구별이 중요합니다. 직접 비교할 수 없습니다.

REST의 기본 목적은 인터넷의 자원 을 나타내고 자원 을 발견하는 메커니즘 을 제공하는 것입니다. 반면에 SOAP는 컴퓨터간에 구조화 된 데이터를 전달하는 데 사용되며 이것이 전부입니다.

인터넷상의 두 컴퓨터 사이에 클라이언트 / 서버 관계를 만들기 위해 실제로 REST가 필요하지 않습니다. JSON 또는 XML을 전송하는 메커니즘 만 있으면되고 다른 사람과 호환되지 않으려는 경우에도 필요하지 않습니다.

그럼에도 불구하고, SOAP는 "공개 계약"을 정의 할 수 있기 때문에 B2B 응용 프로그램에 여전히 일반적으로 사용되지만 새로운 공개 API에는 적합하지 않습니다. JSON 웹 서비스는 다소 가볍고 유연하다는 장점이 있으며 Javascript는 기본적으로 JSON을 인식하므로 브라우저에서 자연스럽게 선택할 수 있습니다.

그러나 그중 아무것도 REST와 관련이 없습니다.

추가 읽기
REST가 REST보다 낫습니까? (REST 프로토콜을 잘못 호출하더라도 좋은 기사).
리차드슨 성숙 모델

REST는 강력 함과 인기 이유 인 SOAP보다 훨씬 제한적입니다.

SOAP에서 허용되는 작업 세트와 허용되는 데이터 유형 세트는 기본적으로 무한합니다. SOAP는 원격 프로 시저 프로토콜로서, 충실도를 잃지 않으면 서 네트워크에서 로컬 API를 노출하는 데 사용됩니다. 이로 인해 복잡한 트랜잭션 시스템이 네트워크를 통해 충실도를 잃지 않고 상호 작용해야하는 엔터프라이즈 환경에서 SOAP이 널리 보급되었습니다. 이 풍부한 기능은 SOAP의 몰락이기도합니다. SOAP API를 이해하고 사용하기가 번거롭기 때문에 WSDL 및 SOAP 클라이언트 라이브러리의 형태로 자동화 된 툴링이 필요하기 때문입니다. 더 나아가, 공개 시스템에있어 풍부한 기본 시스템을 풍부하게 노출시키는 것은 매력적이지 않으며, API를 중단하거나 버전을 변경하지 않고도 기본 시스템을 발전시킬 수있는 추상화를 제공하고자합니다.

REST + JSON은 단순성으로 인해 특히 인기를 얻었습니다. 제한된 데이터 유형으로 제한된 조작 세트를 정의하므로 API 설계자는이 제한된 어휘에 맞는 추상화를 신중하게 설계하고 비즈니스 도메인을 REST 자원에 맵핑하여 실제로 생각해야합니다. REST API는 특별한 툴링없이 이해하기 쉽고 사용하기 쉽습니다. API 사용자가 모든 수준의 기술과 지식을 가질 수있는 공개 API의 경우 이는 정확히 원하는 것이므로 웹에서 볼 수있는 모든 API가 REST로 전환 된 이유입니다. SOAP는 여전히 시스템간에 복잡한 API를 공유하고 싶어하는 엔터프라이즈 상황으로 강등됩니다. 하나,

본질적으로 사람들이 깨달은 것은 API를 간단하고 추상화하여 API를 유지 관리하고 사용하기 쉽도록 API 디자인에 적용해야하는 제약 조건 세트가 REST가 도입 한 제약 조건 세트와 정확히 일치하여 SOAP를 효과적으로 무효화한다는 것입니다. 단점 만 남게하는 이점. SOAP를 사용하여 단순화 된 API를 빌드 할 수 있지만 REST만큼 사용하기가 쉽지 않으므로 실제로는 모두가 REST를 선택하기 만합니다.

REST와 SOAP를 비교할 수 없습니다. REST는 아키텍처 스타일이지만 SOAP은 프로토콜입니다.

불행하게도, REST는 구어체가 RESTful HTTP 서비스와 동의어가되었으며 이는 HTTP (애플리케이션) 프로토콜을 사용하여 REST 스타일 아키텍처를 실현한다는 의미입니다.

REST는 다음과 같은 원칙 (제약 및 요소)을 기반으로합니다 (RESTful HTTP에서의 구현을 괄호로 묶음) [1] .

• 상태 비 저장 (HTTP는 상태 비 저장 프로토콜)
• 자원 (URI로 식별)
• 균일 한 인터페이스 (HTTP 메소드)
• 표현 (MIME-TYPE)
• HATEOS (하이퍼 링크)
• 캐시 (HTTP 캐시)

다른 한편으로 많은 사람들은 W3C 웹 서비스 아키텍처의 일부인 SOAP를 WSDL과 SOAP 기반 웹 서비스라고 말하고있다 [2] .

• SOAP는 정보를 교환하기위한 프로토콜 (기본적으로 메소드 이름, 매개 변수, 리턴 값, 데이터 유형 등)로 사용됩니다.
• WSDL은 웹 서비스를 설명하는 인터페이스 정의 언어입니다.

SOAP *의 현재의 중요성은 무엇입니까?

SOAP는 W3C 표준이며 W3C 웹 서비스에서 정보 교환 형식으로 사용됩니다. 이러한 웹 서비스는 특히 2008 년 (+ -3 년) SOA (서비스 지향 아키텍처)의 과대 광고였으며 (아쉽게도) 여전히 엔터프라이즈 응용 프로그램에서 구현되었습니다.

몇 가지 이유가 있습니다. 그 당시 RESTful HTTP는 잘 알려져 있지 않았으며 오해되었습니다. 불행히도 여전히 다른 답변을 살펴보면 오해가됩니다.

"[...] REST는 SOAP [...]보다 훨씬 제한적입니다."

“RES의 주요 목적은 인터넷에서 리소스를 나타내는 것입니다.

또한 SOAP (및 WSDL)는 W3C 웹 서비스 프로토콜 스택의 일부로 웹 서비스 구현을위한 더 많은 표준을 제공합니다.

사람들이 여전히 새로운 SOAP 기반 API를 개발하고 있습니까, 아니면 지금은 대부분 레거시입니까?

그렇습니다. SOAP를 사용하는 시스템이 여전히 있으며 앞으로도 엔터프라이즈 시스템에서는 대부분 뒤에 있습니다. 그러나 대다수는 요즘 일종의 "REST"를 시도하고있다.

SOAP와 REST의 차이점에 대해 내가 틀렸다면 누군가 나를 수정 해 줄 수 있습니까?

REST가 데이터 전송을위한보다 유연한 상태 비 저장 아키텍처 라고 말하는 것은 좋은 설명이 아닙니다. 간단히 말해 REST는 특정 제약 조건 및 요소가 포함 된 아키텍처 스타일입니다. SOAP는 정보 교환 프로토콜입니다.

내가 이미 쓴 것처럼 당신은 그들을 비교할 수 없습니다. 그러나 RESTful HTTP 웹 서비스를 SOAP / WSDL 웹 서비스와 비교할 수 있습니다.