WSDL vs REST wady i zalety


108

Związane z:

Dlaczego miałoby się używać REST zamiast usług internetowych?

Podejmując decyzję, czy zaimplementować usługę sieciową za pomocą protokołu SOAP lub REST (przez co rozumiem HTTP / XML w sposób RESTful), o czym powinienem wiedzieć i o czym myśleć? Zakładam, że to nie jest jeden rozmiar dla wszystkich, więc jak wybrać, który z nich użyć.


To pytanie może również zawierać przydatne odpowiedzi: stackoverflow.com/questions/90451/…
Rob Hruska

2
To zależy od kontekstu, zarówno SOAP, jak i REST mają swoje miejsce. Zwykle nie widzisz Hi-SOAP i lo-SOAP, tak jak słyszysz o REST. Powodem tego jest specyfikacja i albo się jej przestrzegasz, albo nie. SOAP znajduje zastosowanie w centrach danych, w których wymagana jest interoperacyjność między różnymi serwerami, które nie mogą się bezpośrednio komunikować, a wydajność jest ważnym czynnikiem. W takich przypadkach dobrze jest robić SOAP przez TCP. SOAP został zaprojektowany jako niezależny od transportu, więc zasadniczo powinieneś móc go używać przez TCP, MSMQ itp., REST obsługuje tylko HTTP.
Srikar Doddi

CodeToGlory ma rację. W rzeczywistości program WCF firmy Microsoft został zaprojektowany specjalnie w celu uczynienia protokołu SOAP na dowolnym medium transportowym tak łatwym, jak wartość w pliku konfiguracyjnym.
Travis Heseman

Możliwy duplikat SOAP vs REST (różnice)
Hedeshy

Odpowiedzi:


111

Te dwa protokoły mają bardzo różne zastosowania w świecie rzeczywistym.

SOAP (używający WSDL) to ciężki standard XML, który koncentruje się na przekazywaniu dokumentów. Zaletą tego rozwiązania jest to, że Twoje żądania i odpowiedzi mogą mieć bardzo dobrą strukturę i mogą nawet korzystać z DTD. Wadą jest to, że jest to XML i jest bardzo rozwlekły. Jest to jednak dobre, jeśli dwie strony muszą mieć ścisłą umowę (np. W przypadku komunikacji międzybankowej). SOAP umożliwia także nakładanie na dokumenty warstw takich elementów, jak WS-Security. SOAP jest generalnie niezależny od transportu, co oznacza, że ​​niekoniecznie musisz używać protokołu HTTP.

REST jest bardzo lekki i opiera się na standardzie HTTP. Dobrze jest szybko skonfigurować i uruchomić użyteczną usługę internetową. Jeśli nie potrzebujesz ścisłej definicji API, to jest droga. Większość usług internetowych należy do tej kategorii. Możesz wersjonować swój interfejs API, aby aktualizacje API nie powodowały uszkodzenia go dla osób używających starych wersji (o ile określą wersję). REST zasadniczo wymaga protokołu HTTP i jest niezależny od formatu (co oznacza, że ​​możesz używać XML, JSON, HTML, cokolwiek).

Generalnie używam REST, ponieważ nie potrzebuję wyszukanych funkcji WS- *. SOAP jest jednak dobry, jeśli chcesz, aby komputery rozumiały Twoją usługę sieciową za pomocą WSDL. Specyfikacje REST są generalnie czytelne tylko dla człowieka.


5
@JohnSaunders Po co są koperty, jeśli nie ma dokumentu? Chyba nie powiedziałem, że DTD jest unikalną cechą SOAP. Przepraszam, nie jestem w nastroju do dzisiejszej debaty. Może ponownie przeczytaj komentarze do swojej odpowiedzi na to pytanie sprzed prawie 3 lat. Nie sądzę, żeby ciężki ciężar był koniecznie złą rzeczą, czasami chcesz Holyfield, ale innym razem Pacquiao wykonuje swoją pracę. Nie odbieraj tego źle i nic osobistego :)
Kekoa

1
SOAP działa z interfejsami w stylu dokumentów lub RPC. Ponadto, zgodnie z moją najlepszą wiedzą, SOAP w ogóle nie używa DTD. I nigdy nie określałeś ilościowo „wagi ciężkiej”. Przepraszam, że dopiero co zobaczyłem twoją odpowiedź, albo odrzuciłbym głos trzy lata temu.
John Saunders,

2
@JohnSaunders Życzę miłego dnia!
Kekoa

2
REST, podobnie jak SOAP, jest niezależny od protokołu. Nie opiera się na protokole HTTP, chociaż jest najczęściej używany w ten sposób. Myślę, że ważnym faktem, o którym często nie wspomina się, jest to, że SOAP vs REST porównuje standardowy protokół w3c z luźno zdefiniowanym pragmatycznym wzorcem architektonicznym.
joelmdev

1
@ jm2 Nigdy nie widziałem reszty używanej poza HTTP. Chciałbym zobaczyć, jak czasowniki GET / POST / PUT / DELETE / etc. działa w spoczynku „protokół” bez HTTP. Połączyć?
Kekoa,

33

Poniższe łącza zawierają przydatne informacje na temat WSDL vs REST, w tym zalety i wady

Oto kilka kluczowych punktów

1) SOAP został zaprojektowany dla rozproszonego środowiska obliczeniowego, w którym REST został zaprojektowany dla środowiska punkt-punkt.

2) WADL można wykorzystać do zdefiniowania interfejsu dla usług 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


3
REST został zaprojektowany dla systemów rozproszonych: „[...] styl architektoniczny Representational State Transfer (REST) ​​dla rozproszonych systemów hipermedialnych [...]” (Fielding, 2000) ics.uci.edu/~fielding/pubs/dissertation/ rest_arch_style.htm
Thomas Eizinger

19

Traktowanie WSDL (co oznacza „SOAP”) jako „ciężkiego”. Ciężki ma znaczenie jak? Jeśli zestaw narzędzi wykonuje za Ciebie wszystkie „podnoszenie ciężarów”, dlaczego ma to znaczenie?

Jeszcze nigdy nie potrzebowałem używać skomplikowanego interfejsu API REST. Kiedy to zrobię, spodziewam się, że będę życzył sobie WSDL, który moje narzędzia chętnie przekonwertują na zestaw klas proxy, więc mogę po prostu wywołać coś, co wygląda na metody. Zamiast tego podejrzewam, że aby korzystać z nietrywialnego API opartego na REST, konieczne będzie ręczne napisanie znacznej ilości „lekkiego” kodu.

Nawet jeśli to wszystko zostanie zrobione, nadal będziesz przetłumaczyć dokumentację czytelną dla człowieka na kod, z całym ryzykiem, że ludzie odczytają ją źle. Ponieważ WSDL jest opisem usługi w postaci czytelnej dla komputera, znacznie trudniej jest go „źle odczytać”.


Tylko uwaga: od tego postu, ja już miałem okazję pracować z umiarkowanie skomplikowany usługi REST. Rzeczywiście, marzyłem o WSDL lub jego odpowiedniku i rzeczywiście musiałem napisać ręcznie dużo kodu. W rzeczywistości znaczną część czasu poświęcono na usuwanie powielania kodu całego kodu, który wywoływał różne operacje usługowe „ręcznie”.


Myślę, że „lekki” dotyczy wydajności, powiedzmy na przykład, aby ładować sugerowane wyszukiwane hasła podczas pisania. Jestem facetem .NET i naprawdę doceniam niektóre funkcje IDE podobne do tego, co mówisz (automatycznie generowane klasy proxy), ale dla WS REST. Coś takiego istnieje?
Romias

1
Przykład, który sugerujesz, to prosta usługa REST i prawdopodobnie trudno ją „źle odczytać”. Ponadto każdy, kto uważa, że ​​SOAP działa gorzej, musi to potwierdzić liczbami. Nie miałem wrażenia, o czym fani REST mówią, kiedy mówią „ciężki”.
John Saunders

3
Ciężka waga nie jest obraźliwa, miałem na myśli tylko, że SOAP daje ci dużo i ma trochę wydajności i złożoności ceny. W boksie waga ciężka może prawdopodobnie wyrządzić więcej szkód niż waga lekka, ale lekki może wykonać swoją pracę w momentach, gdy waga ciężka nie jest wymagana. Ponadto dodatkowe „rzeczy”, takie jak WS-Security lub Transactions, wprowadzają dodatkową złożoność, której REST po prostu nie ma.
Kekoa

3
„poprzyj to liczbami” - klasyczna przynęta na płomień. Jestem fanem obu, ale żaden nie jest uniwersalny.
Kekoa

4
@kekoav: Odpowiadałem Romiasowi, mówiąc, że jego zdaniem „lekki” dotyczy wydajności. Czułem, że powinien to poprzeć każdy, kto tak czuje. Poza tym nie zakładałbym lepszej wydajności bez jej pomiaru i nie mierzyłbym na przykład transakcji w porównaniu z brakiem transakcji lub WS-Security w porównaniu z HTTPS. Sugerowanie weryfikacji stwierdzenia nie jest przynętą na ogień.
John Saunders

15

To prawdopodobnie naprawdę należy do komentarzy w kilku z powyższych postów, ale nie mam jeszcze przedstawiciela, który mógłby to zrobić, więc proszę.

Myślę, że to interesujące, że wiele zalet i wad często przytaczanych w przypadku SOAP i REST ma niewiele wspólnego z rzeczywistymi wartościami lub ograniczeniami tych dwóch technologii. Prawdopodobnie najczęściej cytowaną zaletą REST jest to, że jest „lekki” lub bardziej „czytelny dla człowieka”. Na pewnym poziomie jest to z pewnością prawda, REST ma niższą barierę wejścia - jest mniej wymagana struktura niż SOAP (chociaż zgadzam się z tymi, którzy powiedzieli, że dobre oprzyrządowanie jest tutaj w dużej mierze odpowiedzią - szkoda, że ​​większość narzędzi SOAP jest dość okropne).

Poza tym początkowym kosztem wejścia myślę, że wrażenie REST pochodzi z połączenia postaci adresów URL żądań i złożoności danych wymienianych przez większość usług REST. REST ma tendencję do zachęcania do prostszych, bardziej czytelnych dla człowieka adresów URL żądań, a dane są również łatwiejsze do strawienia. W jakim jednak stopniu są one nieodłączne dla REST, a do jakiego stopnia są one tylko przypadkowe. Prostsza struktura adresu URL jest bezpośrednim wynikiem architektury - ale można ją równie dobrze zastosować do usług opartych na protokole SOAP. Bardziej strawne dane są prawdopodobnie wynikiem braku określonej struktury. Oznacza to, że lepiej utrzymuj proste formaty danych, w przeciwnym razie będziesz mieć dużo pracy. Więc tutaj dodatkowa struktura SOAP,

Tak więc, jeśli chodzi o wymianę ustrukturyzowanych danych między systemami komputerowymi, nie jestem pewien, czy REST jest z natury lepszy niż SOAP (lub odwrotnie), są po prostu inne. Myślę, że powyższe porównanie REST vs SOAP z dynamicznym vs statycznym typowaniem jest dobre. Tam, gdzie języki dynamiczne mają tendencję do wpadania w kłopoty, jest długoterminowe utrzymanie i utrzymanie systemu (a na dłuższą metę nie mówię o roku lub 2, mówię o 5 lub 10). Ciekawie będzie zobaczyć, czy REST napotyka z czasem te same wyzwania. Wydaje mi się, że tak będzie, więc gdybym budował rozproszony system przetwarzania informacji, skłoniłbym się do SOAP jako mechanizmu komunikacji (również ze względu na transmisję i warstwowość protokołu aplikacji oraz elastyczność, którą zapewnia, jak wspomniano powyżej).

W innych miejscach REST wydaje się bardziej odpowiedni. AJAX między klientem a jego serwerem (niezależnie od ładunku) jest jednym z głównych przykładów. Nie przejmuję się długowiecznością tego typu połączeń, a łatwość obsługi i elastyczność są na najwyższym poziomie. Podobnie, gdybym potrzebował szybkiego dostępu do jakiejś usługi zewnętrznej i nie sądziłem, że będę się przejmował utrzymywalnością interakcji w czasie (ponownie zakładam, że to jest miejsce, w którym REST będzie mnie kosztować więcej, w jedną stronę lub inny), wtedy mógłbym wybrać REST, aby móc szybko wchodzić i wychodzić.

W każdym razie obie są realnymi technologiami iw zależności od tego, jakie kompromisy chcesz osiągnąć dla danej aplikacji, mogą Ci służyć dobrze (lub słabo).


5

REST nie jest protokołem; To styl architektoniczny. Albo paradygmat, jeśli chcesz. Oznacza to, że jest dużo luźniej zdefiniowane, że SOAP jest. W przypadku podstawowego CRUD możesz polegać na standardowych protokołach, takich jak Atompub, ale w przypadku większości usług będziesz mieć więcej poleceń niż tylko to.

Jako konsument, SOAP może być błogosławieństwem lub przekleństwem, w zależności od obsługiwanego języka. Ponieważ SOAP jest w dużej mierze wzorowany na systemie ściśle wpisywanym, najlepiej działa z językami z typami statycznymi. Dla dynamicznego języka łatwo może stać się okrucieństwem i zbytecznym. Ponadto obsługa bibliotek klienta nie jest tak dobra poza światem Java i .NET


Czy jest jakiś uzasadniony powód słabej obsługi narzędzi poza Java i .NET? Czy w pliku WSDL brakuje czegoś, co uniemożliwiłoby, powiedzmy, utworzenie proxy Ruby?
John Saunders

Technicznie nie, ale ktoś musi to zaimplementować, a ani Sun (przepraszam, Oracle), ani Microsoft nie będą nikomu płacić za implementację bibliotek klienckich w Rubim. Protokół SOAP jest dość złożony. Dodaj do tego fakt, że cała złożoność tkwi w systemie typów, który z perspektywy dynamicznego języka jest po prostu śmieciem. Można więc powiedzieć, że SOAP wymusza statyczne systemy typów na dynamicznych językach. REST to coś zupełnie odwrotnego.
troelskn

4

Według mnie powinniśmy być ostrożni, kiedy używamy słowa usługa internetowa. Powinniśmy cały czas określać, czy mówimy o usłudze sieciowej SOAP, usłudze sieciowej REST lub innym rodzaju usługach internetowych, ponieważ mówimy tutaj o różnych rzeczach, a ludzie nie rozumieją już, jeśli nazwaliśmy je wszystkie usługami sieciowymi.

Zasadniczo usługi sieciowe SOAP są bardzo dobrze znane od lat i podlegają ścisłej specyfikacji, która opisuje, jak komunikować się z nimi w oparciu o specyfikację SOAP. Teraz usługi internetowe REST są nieco nowsze i zasadniczo wyglądają na prostsze, ponieważ nie używają żadnego protokołu komunikacyjnego. Zasadniczo to, co wysyłasz i otrzymujesz podczas korzystania z usługi internetowej REST, to zwykły XML. Ludziom się to podoba, ponieważ mogą analizować XML tak, jak chcą, bez konieczności korzystania z bardziej wyrafinowanego protokołu komunikacyjnego, takiego jak SOAP.

Dla mnie usługi REST są prawie takie, jak gdybyś utworzył serwlet zamiast usługi sieciowej SOAP. Aplet pobiera i zwraca dane. Dane mają format XML. Możemy również wyobrazić sobie użycie czegoś innego niż XML, jeśli chcemy. Na przykład tagi mogą być używane zamiast xml i nie byłoby to już REST, ale coś innego (mogłoby być jeszcze lżejsze pod względem wagi, ponieważ xml nie jest z natury lekki). Czy nazwalibyśmy to nadal usługą internetową? Tak, moglibyśmy, ale to nie będzie zgodne z żadnym obecnym standardem i jest to główny problem, jeśli zaczniemy nazywać wszystkie usługi internetowe, ale możemy to zrobić tak, jak chcemy, wtedy tracimy na interoperacyjności. Oznacza to, że format danych wymienianych z usługą sieciową nie jest już ustandaryzowany.

To, co ludziom nie podoba się w SOAP, to to, że mają trudności z jego zrozumieniem i nie mogą ręcznie generować zapytań. Komputery potrafią to jednak zrobić bardzo dobrze, więc musimy to wyjaśnić: czy zapytania i odpowiedzi usług internetowych mają być używane bezpośrednio przez użytkowników końcowych, czy też zgadzamy się, że usługi internetowe są pod interfejsem API wywoływanym przez systemy komputerowe oparte na pewnych znormalizowanych standardy?


1
To nie byłby już REST?
Steven Shaw

3

SOAP : Może być również przesyłany przez SMTP, co oznacza, że ​​możemy wywołać usługę za pomocą prostego formatu tekstowego poczty e-mail

Potrzebuje dodatkowej struktury / silnika, który powinien znajdować się na maszynie konsumenckiej usługi internetowej, aby konwertować wiadomość SOAP na odpowiednią strukturę obiektów w różnych językach.

REST : teraz WSDL2.0 obsługuje również opisywanie usługi WWW REST

Możemy użyć, gdy chcesz, aby Twoja usługa była lekka, na przykład dzwonienie z urządzeń mobilnych, takich jak telefon komórkowy, PDA itp.


Dzięki za poruszenie tego, @Jenith. Wydaje się, że nikt nie chce o tym mówić. WSDL ma do czynienia z opisem. REST to paradygmat. Dla innych: zapoznaj się z wprowadzeniem na stronie ibm.com/developerworks/webservices/library/ws-restwsdl . Tym samym oryginalne pytanie (biorąc pod uwagę datę jego wpisu) wskazuje, że tytuł pytania jest źle dobrany (prawdopodobnie ma na myśli WSDL 1.0).
Sonny

3

w przypadku systemów korporacyjnych, w których Twój system jest ograniczony do korporacji, jego użycie jest łatwiejsze i właściwe, ponieważ masz prawie kontrolę nad klientami. jest to łatwiejsze, ponieważ istnieje wiele narzędzi, które tworzą klasy (proxy) i wyglądają tak, jakbyś robił swoje zwykłe OOP, które pasuje do twojego środowiska java lub .net (z którego korzysta większość firm).

Używałbym REST do aplikacji internetowych do ujawniania interfejsów (takich jak Twitter api), ponieważ klienci mogą używać javascripts, html lub innych, w których pisanie nie jest ścisłe. Bardziej liberalny REST ma większy sens.

Również dla klientów z dostępem do Internetu (WWW), łatwiej jest przeanalizować json lub xml wychodzące z interfejsu REST zamiast czysto XML pochodzącego z interfejsu mydła. Trudno jest używać proxy w javascript, a javascript nie obsługuje naturalnie obiektów. Jeśli używasz REST z javascript, zwykle parsujesz ciąg json i jesteś wyłączony. Interfejsy internetowe są zwykle bardzo proste (więc w większości przypadków jest to proste parsowanie) i zwykle nie wymagają spójności, dlatego REST jest wystarczający.

W przypadku aplikacji korporacyjnych nie sądzę, aby REST był odpowiedni, ponieważ transakcje, bezpieczeństwo, ścisłe pisanie, schematy odgrywają bardzo ważną rolę w tworzeniu aplikacji korporacyjnych, dlatego SOAP jest dla nich bardziej odpowiedni.

Mój wniosek jest taki, że SOAP jest przeznaczony dla systemów korporacyjnych, REST jest dla Internetu lub WWW. Możesz go używać zamiennie, ale możesz mieć trudności z użyciem odpowiedniego narzędzia do pracy.

Przepraszam za mój zły angielski.


2

W obronie REST ściśle przestrzega zasad HTTP i adresowalności, np. Operacje odczytu używają GET, operacje aktualizacji używają POST itp. Uważam, że jest to znacznie czystsze podejście. Książka Oreilly RESTful Web Services wyjaśnia to znacznie lepiej niż ja, jeśli ją czytasz, myślę, że wolałbyś podejście REST


1

Zestaw narzędzi po stronie klienta byłby jednym. A znajomość usług SOAP druga. Obecnie coraz więcej usług korzysta z protokołu RESTful, a testowanie takich usług można przeprowadzić na prostych przykładach cURL. Chociaż nie jest wcale takie trudne, aby wdrożyć obie metody i pozwolić na jak najszersze wykorzystanie przez klientów.

Jeśli chcesz wybrać jeden, proponuję REST, jest łatwiej.


1

Poprzednie odpowiedzi zawierają wiele informacji, ale myślę, że istnieje różnica filozoficzna, na którą nie zwrócono uwagi. SOAP był odpowiedzią na pytanie „jak stworzyć nowoczesnego, zorientowanego obiektowo, niezależnego od platformy i protokołu następcę RPC?”. REST powstał na podstawie pytania „jak wykorzystać spostrzeżenia, które sprawiły, że protokół HTTP odniósł tak duży sukces w sieci Web i wykorzystać je do przetwarzania rozproszonego”?

SOAP polega na dostarczeniu narzędzi, dzięki którym programowanie rozproszone będzie wyglądać jak ... programowanie. REST próbuje narzucić styl upraszczający rozproszone interfejsy, tak aby rozproszone zasoby mogły odnosić się do siebie tak, jak rozproszone strony HTML mogą odnosić się do siebie nawzajem. Jednym ze sposobów jest próba (głównie) ograniczenia operacji do „CRUD” na zasobach (tworzenie, odczytywanie, aktualizowanie, usuwanie).

REST jest wciąż młody - chociaż jest zorientowany na usługi „czytelne dla człowieka”, nie wyklucza usług introspekcji itp. Ani automatycznego tworzenia serwerów proxy. Jednak te nie zostały ustandaryzowane (jak piszę). SOAP daje ci te rzeczy, ale (IMHO) daje ci "tylko" te rzeczy, podczas gdy styl narzucony przez REST już zachęca do rozpowszechniania usług internetowych ze względu na jego prostotę. Sam bym zachęcał początkujących dostawców usług do wyboru REST, chyba że istnieją określone funkcje dostarczane przez SOAP, z których muszą korzystać.

Moim zdaniem więc, jeśli wdrażasz API "od podstaw" i nie wiesz zbyt wiele o potencjalnych klientach, wybrałbym REST, ponieważ styl, który zachęca, ma na celu uczynienie interfejsów zrozumiałymi i łatwymi do rozwijania. Jeśli wiesz dużo o kliencie i serwerze, a istnieją konkretne narzędzia SOAP, które ułatwią życie obu, to nie byłbym religijny w kwestii REST.


-1: to właściwie nie odpowiada na pytanie. Mówi niewiele lub nic o tym, „dlaczego powinienem wybrać jeden z nich”?
John Saunders

1
Skoncentrowałem się na dostarczeniu informacji, których inni nie chcieli - ale dodałem wniosek, biorąc pod uwagę twoją podpowiedź.
shaunc

0

Możesz łatwo przenieść składniki sieci Web WCF z wypluwaniem WSDL do innych zastosowań, po prostu zmieniając ustawienia konfiguracji. Możesz przejść przez HTTP, a następnie nazwać potoki, tcp, niestandardowe protokoły itp. Bez konieczności zmiany kodu. Uważam, że komponenty WCF mogą być również łatwiejsze do skonfigurowania dla rzeczy takich jak bezpieczeństwo, połączenia dwukierunkowe, transakcje, współbieżność itp.

REST prawie ogranicza cię do HTTP (co w wielu przypadkach jest w porządku).


0

Wiem, że ta dyskusja jest stara, ale po przeczytaniu wszystkich odpowiedzi i skomentowaniu uważam, że wszyscy przegapili najważniejszy punkt dotyczący różnicy między dwoma systemami: SOAP używa złożonych typów, aby nie tylko podać dane, ale także zweryfikować go i zachowaj w ścisłym oznaczeniu typu, dla którego został zdefiniowany. WSDL informuje, jaki jest format danych, jaki jest typ danych, umożliwia dodawanie reguł w stylu wzorca reg-ex i określa, ile razy dane muszą być i mogą być dozwolone w żądaniu / odpowiedzi . Reszta z drugiej strony nie ma żadnego z tych mechanizmów.

SOAP jest złożony i ciężki, ponieważ umożliwia wysyłanie złożonych ciężkich danych hierarchicznych. REST to zwykły tekst, z punktem początkowym i końcowym porządkującym reguły.

SOAP jest niezależny od biznesu, ponieważ ma wszystkie reguły danych osadzone w dokumencie.

Różnica między SOAP i REST polega na tym, że SOAP jest samodzielnym schematem biznesowym. REST to dokument tekstowy.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.