[web-services] WSDL 대 REST 장단점

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

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를 선택하여 신속하게 출입 할 수 있습니다.

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

답변