WSDL 대 REST 장단점

관련 :

웹 서비스 대신 REST를 사용하는 이유는 무엇입니까?

SOAP 또는 REST (즉, RESTful 방식의 HTTP / XML을 의미 함)를 사용하여 웹 서비스를 구현할지 여부를 결정할 때 무엇을 알고 있어야하며 무엇을 생각해야합니까? 나는 이것이 모든 것에 맞는 하나의 크기가 아니라고 생각하므로 사용할 것을 어떻게 선택합니까?

두 프로토콜은 실제 세계에서 매우 다른 용도로 사용됩니다.

SOAP (WSDL 사용)는 문서 전달을 중심으로하는 무거운 XML 표준입니다. 이것의 장점은 요청과 응답이 매우 잘 구조화 될 수 있고 DTD를 사용할 수도 있다는 것입니다. 단점은 XML이고 매우 장황하다는 것입니다. 그러나 두 당사자가 엄격한 계약 (예 : 은행 간 통신)을해야하는 경우에 좋습니다. SOAP를 사용하면 문서에서 WS-Security와 같은 항목을 계층화 할 수 있습니다. SOAP는 일반적으로 전송에 구애받지 않으므로 반드시 HTTP를 사용할 필요는 없습니다.

REST는 매우 가볍고 HTTP 표준에 의존하여 작동합니다. 유용한 웹 서비스를 빠르게 시작하고 실행하는 것이 좋습니다. 엄격한 API 정의가 필요하지 않은 경우 이것이 갈 길입니다. 대부분의 웹 서비스가이 범주에 속합니다. API 업데이트로 인해 이전 버전을 사용하는 사람들이 버전을 지정하는 한 중단되지 않도록 API 버전을 지정할 수 있습니다. REST는 기본적으로 HTTP를 필요로하며 형식에 구애받지 않습니다 (즉, XML, JSON, HTML 등을 사용할 수 있음).

일반적으로 나는 멋진 WS- * 기능이 필요하지 않기 때문에 REST를 사용합니다. 컴퓨터가 WSDL을 사용하여 웹 서비스를 이해하도록하려면 SOAP가 좋습니다. REST 사양은 일반적으로 사람이 읽을 수만 있습니다.

다음 링크는 장점과 단점을 포함하여 WSDL과 REST에 대한 유용한 정보를 제공합니다.

몇 가지 핵심 사항은

1) SOAP는 REST가 점대 점 환경을 위해 설계된 분산 컴퓨팅 환경을 위해 설계되었습니다.

2) WADL을 사용하여 REST 서비스에 대한 인터페이스를 정의 할 수 있습니다.

http://www.ajaxonomy.com/2008/xml/web-services-part-1-soap-vs-rest
http://ajaxonomy.com/2008/xml/web-services-part-2-wsdl-and -wadl

WSDL ( "SOAP"을 의미)을 "무거운 무게"로 간주합니다. 헤비는 어떻게 중요합니까? 도구 세트가 모든 "무거운 작업"을 수행하는 경우 왜 중요합니까?

아직 복잡한 REST API를 사용할 필요가 없습니다. 그렇게 할 때 내 도구가 프록시 클래스 집합으로 기꺼이 변환되는 WSDL을 원할 것으로 예상되므로 메서드로 보이는 것을 호출 할 수 있습니다. 대신, 사소하지 않은 REST 기반 API를 사용하려면 상당한 양의 "경량"코드를 직접 작성해야한다고 생각합니다.

모든 작업이 완료 되더라도 사람이 읽을 수있는 문서를 코드로 변환하고 사람이 잘못 읽을 위험이 있습니다. WSDL은 기계가 읽을 수있는 서비스 설명이므로 "잘못 읽는"것이 훨씬 더 어렵습니다.

그냥 참고 :이 게시물 이후로, 나는 한 적당히 복잡 REST 서비스와 함께 일할 수있는 기회가 있었다. 나는 실제로 WSDL이나 이에 상응하는 것을 원했고 실제로 많은 코드를 직접 작성해야했다. 실제로 개발 시간의 상당 부분을 "수작업으로"서로 다른 서비스 작업을 호출하는 모든 코드의 코드 중복을 제거하는 데 소비되었습니다.

이것은 아마도 위의 여러 게시물에 대한 주석으로 속할 수 있지만 아직 그렇게 할 담당자가 없으므로 여기에 있습니다.

SOAP와 REST에서 자주 인용되는 많은 장단점이 두 기술의 실제 값이나 한계와 거의 관련이 없다는 것이 흥미 롭다고 생각합니다. 아마도 REST에 대해 가장 많이 인용되는 장점은 "가벼움"이거나 "인간이 읽을 수있는"경향이 있다는 것입니다. 한 수준에서 이것은 확실히 사실입니다. REST는 진입 장벽이 낮습니다. SOAP보다 필요한 구조가 적습니다 (하지만 여기에서는 좋은 도구가 대부분의 해답이라고 말한 사람들에게 동의하지만 SOAP 도구의 대부분이 너무 나쁩니다. 꽤 무서운).

그러나 초기 진입 비용 외에도 REST 인상은 요청 URL의 형식과 대부분의 REST 서비스에서 교환하는 데이터의 복잡성의 조합에서 비롯된 것이라고 생각합니다. REST는 더 간단하고 사람이 읽을 수있는 요청 URL을 장려하는 경향이 있으며 데이터도 더 소화하기 쉬운 경향이 있습니다. 그러나 이들은 REST에 내재되어있는 정도와 단지 우발적 일 정도입니다. 더 간단한 URL 구조는 아키텍처의 직접적인 결과이지만 SOAP 기반 서비스에도 똑같이 잘 적용될 수 있습니다. 더 소화하기 쉬운 데이터는 정의 된 구조가 없기 때문일 가능성이 높습니다. 즉, 데이터 형식을 단순하게 유지하거나 많은 작업을 수행 할 것입니다. 그래서 여기 SOAP의 추가 구조,

따라서 컴퓨터 시스템 간의 구조화 된 데이터 교환에 사용하기 위해 REST가 본질적으로 SOAP (또는 그 반대)보다 낫다는 것은 확실하지 않습니다. 위의 REST 대 SOAP와 동적 대 정적 형식의 비교가 좋은 것이라고 생각합니다. 동적 언어가 문제를 일으키는 경향이있는 곳은 시스템의 장기적인 유지 관리 및 유지에 있습니다 (그리고 장기적으로는 1 년 또는 2 년이 아니라 5 ~ 10 년을 말하는 것입니다). REST가 시간이 지남에 따라 동일한 문제에 직면하는지 확인하는 것은 흥미로울 것입니다. 분산 된 정보 처리 시스템을 구축한다면 통신 메커니즘으로 SOAP를 선호 할 것이라고 생각하는 경향이 있습니다 (위에서 언급 한대로 전송 및 애플리케이션 프로토콜 계층화 및 유연성 때문에).

다른 곳에서는 REST가 더 적절 해 보입니다. 페이로드에 관계없이 클라이언트와 서버 간의 AJAX가 한 가지 주요 예입니다. 나는 이러한 유형의 연결의 수명에 대해별로 신경 쓰지 않으며 사용의 용이성과 유연성이 최고입니다. 유사하게 외부 서비스에 대한 빠른 액세스가 필요하고 시간이 지남에 따라 상호 작용의 유지 관리 가능성에 대해 신경 쓰지 않을 것이라고 생각했다면 (다시 말하지만 REST가 더 많은 비용을 지불하게 될 것이라고 가정하고 있습니다. 또는 다른), REST를 선택하여 신속하게 출입 할 수 있습니다.

어쨌든 둘 다 실행 가능한 기술이며 주어진 응용 프로그램에 대해 어떤 장단점을 만들고 싶은지에 따라 잘 (또는 좋지 않은) 서비스를 제공 할 수 있습니다.

REST는 프로토콜이 아닙니다. 건축 스타일입니다. 또는 원하는 경우 패러다임. 즉, SOAP가 정의 된 것이 훨씬 느슨하다는 것을 의미합니다. 기본 CRUD의 경우 Atompub와 같은 표준 프로토콜에 의존 할 수 있지만 대부분의 서비스에는 그 이상의 명령이 있습니다.

소비자로서 SOAP는 언어 지원에 따라 축복 또는 저주가 될 수 있습니다. SOAP는 엄격하게 유형이 지정된 시스템에서 모델링되므로 정적으로 유형이 지정된 언어에서 가장 잘 작동합니다. 동적 인 언어의 경우 쉽게 엉망이되고 불필요해질 수 있습니다. 또한 클라이언트 라이브러리 지원은 Java 및 .NET의 세계 밖에서는 좋지 않습니다.

나에게 우리는 웹 서비스라는 단어를 사용할 때주의해야합니다. SOAP 웹 서비스, REST 웹 서비스 또는 다른 종류의 웹 서비스에 대해 이야기하고 있는지 항상 지정해야합니다. 여기에서 다른 것에 대해 이야기하고 있고 모든 웹 서비스의 이름을 지정하면 사람들이 더 이상 이해하지 못하기 때문입니다.

기본적으로 SOAP 웹 서비스는 수년 동안 매우 잘 확립되어 있으며 SOAP 사양을 기반으로 통신하는 방법을 설명하는 엄격한 사양을 따릅니다. 이제 REST 웹 서비스는 조금 더 새롭고 통신 프로토콜을 사용하지 않기 때문에 기본적으로 더 간단 해 보입니다. 기본적으로 REST 웹 서비스를 사용할 때 보내고받는 것은 일반 XML입니다. 사람들은 SOAP와 같은보다 정교한 통신 프로토콜을 처리 할 필요없이 원하는 방식으로 xml을 구문 분석 할 수 있기 때문에이를 좋아합니다.

나에게 REST 서비스는 SOAP 웹 서비스 대신 서블릿을 만드는 것과 거의 같습니다. 서블릿은 데이터를 가져오고 데이터를 반환합니다. 데이터 형식은 xml 기반입니다. 원한다면 xml이 아닌 다른 것을 사용하는 것을 상상할 수도 있습니다. 예를 들어 태그는 xml 대신 사용할 수 있으며 더 이상 REST가 아니라 다른 것입니다 (xml은 본질적으로 가볍지 않기 때문에 가중치 측면에서 더 가벼울 수 있음). 여전히 웹 서비스라고 부를까요? 예, 할 수는 있지만 현재 표준을 따르지 않을 것이며 모든 웹 서비스를 호출하기 시작하면 여기에서 주요 문제가됩니다. 그러나 우리가 원하는 방식으로 할 수 있고 상호 운용성 측면을 잃어 버리는 것입니다. 이는 웹 서비스와 교환되는 데이터의 형식이 더 이상 표준화되지 않음을 의미합니다.

사람들이 SOAP에 대해 싫어하는 점은 이해하기 어렵고 수동으로 쿼리를 생성 할 수 없다는 것입니다. 컴퓨터는이를 매우 잘 수행 할 수 있지만 여기에서 명확해야합니다. 웹 서비스 쿼리 및 응답이 최종 사용자에 의해 직접 사용되어야하는지 아니면 웹 서비스가 일부 정규화 된 기반의 컴퓨터 시스템에서 호출되는 API 아래에 있다는 데 동의합니까? 표준?

SOAP : SMTP를 통해 전송 될 수도 있습니다. 즉, 이메일 단순 텍스트 형식을 사용하여 서비스를 호출 할 수도 있습니다.

SOAP 메시지를 다양한 언어의 각 객체 구조로 변환하려면 웹 서비스 소비자 컴퓨터에 추가 프레임 워크 / 엔진이 있어야합니다.

REST : 이제 WSDL2.0은 REST 웹 서비스도 설명하도록 지원합니다.

예를 들어 휴대 전화, PDA 등과 같은 모바일 장치에서 전화를 거는 등 서비스를 경량으로 만들고 싶을 때 사용할 수 있습니다.

귀하의 시스템이 회사 내에 제한되어있는 엔터프라이즈 시스템의 경우 거의 클라이언트를 제어하기 때문에 비누를 사용하는 것이 더 쉽고 적절합니다. 클래스 (프록시)를 생성하고 Java 또는 .net 환경 (대부분의 기업이 사용하는)과 일치하는 일반 OOP를 수행하는 것처럼 보이는 다양한 도구가 있기 때문에 더 쉽습니다.

클라이언트가 javascript, html 또는 타이핑이 엄격하지 않은 다른 것을 사용할 수 있기 때문에 인터페이스 (예 : twitter api)를 노출하기 위해 인터넷 연결 애플리케이션에 REST를 사용합니다. REST가 더 자유 롭다는 것이 더 의미가 있습니다.

또한 인터넷에 직면 한 클라이언트 (월드 와이드 웹)의 경우 SOAP 인터페이스에서 나오는 순수한 xml보다는 나머지 인터페이스에서 나오는 json 또는 xml을 구문 분석하기가 더 쉽습니다. 자바 스크립트에서 프록시를 사용하는 것은 어렵고 자바 스크립트는 자연스럽게 객체를 지원하지 않습니다. 자바 스크립트와 함께 REST를 사용하는 경우 일반적으로 json 문자열을 구문 분석하고 종료됩니다. 인터넷 인터페이스는 일반적으로 매우 간단하며 (대부분의 경우 간단한 구문 분석) 일관성을 요구하지 않으므로 REST가 충분합니다.

엔터프라이즈 애플리케이션의 경우 트랜잭션, 보안, 엄격한 유형 지정, 스키마가 엔터프라이즈 애플리케이션 개발에서 매우 중요하기 때문에 REST가 적절하지 않다고 생각합니다. 그래서 SOAP가 더 적합합니다.

내 결론은 SOAP는 엔터프라이즈 시스템 용이고 REST는 인터넷 또는 WWW 용이라는 것입니다. 서로 바꿔서 사용할 수 있지만 결국 올바른 도구를 사용하지 않는 데 어려움을 겪을 수 있습니다.

내 하찮은 영어 실력에 죄송하다는 말씀을 드리고 싶습니다.

REST를 방어하기 위해 읽기 작업은 GET을 사용하고 업데이트 작업은 POST를 사용하는 등 HTTP 및 주소 지정 가능성의 원칙을 밀접하게 따릅니다.이 방법이 훨씬 더 깔끔한 접근 방식이라고 생각합니다. Oreilly의 책 RESTful Web Services는 이것을 제가 할 수있는 것보다 훨씬 더 잘 설명합니다. 읽으면 REST 접근 방식을 선호 할 것 같습니다.

클라이언트 측의 도구 세트는 하나입니다. 그리고 다른 SOAP 서비스에 대한 친숙 함. 요즘 점점 더 많은 서비스가 RESTful 경로로 가고 있으며 이러한 서비스를 간단한 cURL 예제로 테스트 할 수 있습니다. 그러나 두 가지 방법을 모두 구현하고 클라이언트에서 가장 광범위한 활용을 허용하는 것은 그리 어렵지 않습니다.

하나를 선택해야한다면 REST를 제안하는 것이 더 쉽습니다.

이전 답변에는 많은 정보가 포함되어 있지만 지적되지 않은 철학적 차이가 있다고 생각합니다. SOAP는 "어떻게하면 RPC에 대한 현대적인 객체 지향 플랫폼 및 프로토콜 독립 후속 제품을 만들 수 있습니까?"에 대한 대답이었습니다. REST는 "웹에서 HTTP를 성공적으로 만든 통찰력을 어떻게 분산 컴퓨팅에 사용할 수 있을까?"라는 질문에서 개발되었습니다.

SOAP는 분산 프로그래밍을 프로그래밍처럼 보이게하는 도구를 제공하는 것입니다. REST는 분산 된 인터페이스를 단순화하는 스타일을 적용하여 분산 된 HTML 페이지가 서로를 참조 할 수있는 것처럼 분산 된 리소스가 서로를 참조 할 수 있도록합니다. 이를 수행하는 한 가지 방법은 리소스 (생성, 읽기, 업데이트, 삭제)에서 작업을 "CRUD"로 제한하는 것입니다.

REST는 아직 어리다. 비록 "사람이 읽을 수있는"서비스를 지향하고 있지만 내부 검사 서비스 등이나 자동 프록시 생성을 배제하지는 않습니다. 그러나 이것들은 표준화되지 않았습니다. SOAP는 이러한 기능을 제공하지만 (IMHO)는 이러한 기능만을 제공하는 반면 REST에서 지정한 스타일은 단순성 때문에 이미 웹 서비스의 확산을 장려하고 있습니다. 필자는 자신이 사용해야하는 특정 SOAP 제공 기능이없는 한 초보자 서비스 공급자가 REST를 선택하도록 권장합니다.

제 생각에 "그린 필드"API를 구현하고 있고 가능한 클라이언트에 대해 잘 모르는 경우 인터페이스를 이해하고 개발하기 쉽게 만드는 데 도움이되는 스타일로 REST를 선택합니다. 클라이언트와 서버에 대해 많이 알고 있고 둘 다 쉽게 사용할 수있는 특정 SOAP 도구가 있다면 저는 REST에 대해 종교적이지 않을 것입니다.

구성 설정을 변경하는 것만으로 WSDL 기반 WCF 웹 구성 요소를 다른 용도로 쉽게 전환 할 수 있습니다. 코드를 변경하지 않고도 HTTP와 명명 된 파이프, tcp, 사용자 지정 프로토콜 등을 살펴볼 수 있습니다. 보안, 양방향 호출, 트랜잭션, 동시성 등과 같은 항목에 대해 WCF 구성 요소를 설정하는 것이 더 쉬울 수도 있습니다.

REST는 HTTP로 제한합니다 (대부분의 경우 괜찮습니다).

이 토론이 오래된 토론이라는 것을 알고 있지만 모든 답변을 읽고 의견을 말한 후 모든 사람이 두 시스템의 차이점에 대한 가장 중요한 점을 놓쳤다 고 생각합니다. SOAP는 복잡한 유형을 사용하여 데이터를 제공 할뿐만 아니라 유효성을 검사합니다. 정의 된 엄격한 유형 지정으로 유지하십시오. WSDL은 데이터 형식이 무엇인지, 데이터 유형이 무엇인지 알려주고, 정규식 패턴 스타일 규칙을 추가 할 수 있도록하며, 데이터 조각이 요청 / 응답에서 허용되어야하는 횟수와 허용 될 수있는 횟수를 정의합니다. . 반면에 휴식에는 이러한 메커니즘이 없습니다.

SOAP는 복잡하고 무거운 계층 적 데이터를 보낼 수 있기 때문에 복잡하고 무겁습니다. REST는 규칙을 정렬하는 원본과 끝 점이있는 일반 텍스트입니다.

SOAP는 문서에 모든 데이터 규칙이 포함되어 있으므로 비즈니스에 독립적입니다.

SOAP와 REST의 차이점은 SOAP는 자체 포함 된 비즈니스 지향 스키마라는 것입니다. REST는 텍스트 문서입니다.