관련 :
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 등과 같은 모바일 장치에서 전화를 거는 등 서비스를 경량으로 만들고 싶을 때 사용할 수 있습니다.
