O ile widzę, zużywanie SOAP wymaga stosu SOAP, więc twoi klienci są trudniej zużywać, tj. Muszą upewnić się, że mają stos SOAP, który poprawnie formatuje dane POST i nagłówki, a następnie daje ci trochę struktura danych, podczas gdy za pomocą REST po prostu wysyłasz żądanie HTTP GET z argumentami w ciągu zapytania i otrzymujesz tekst, który, jak sądzę, jest prawdopodobnie XML.
Co zatem daje dodatkowe obciążenie / złożoność SOAP, kiedy jest to potrzebne, a kiedy można i należy bez niego?
Odpowiedzi:
Wcześniej zaimplementowałem interfejs API REST i bardzo mi się podobało. Zasadniczo, kiedy implementujesz REST przez SOAP, twój klient / serwer jest bardziej ortogonalny, co oznacza, że możesz o wiele bardziej swobodnie zmieniać serwer bez wpływu na twoich klientów. Ta ortogonalność wynika z zastosowania bardziej abstrakcyjnej i już dobrze zdefiniowanej komunikacji za pomocą czasowników HTTP. Ponadto użycie hiperłączy zawartych w odpowiedziach REST ułatwia rozszerzenie i rozbudowę interfejsu API stosunkowo bezboleśnie. Klienci powinni podążać za tymi osadzonymi linkami, aby uzyskać dostęp do nowych zasobów, tak jak człowiek podążałby za linkami na stronie internetowej, aby „uzyskać więcej informacji”.
Powiedziawszy to, miałem kilku współpracowników, którym powiedziano, że muszą używać SOAP i narzekali na to przez cały czas. Więc zająłem się badaniem tych dwóch bardziej szczegółowo.
Ogólnie stwierdziłem, że REST dobrze nadaje się do wysoce rozproszonych aplikacji , gdy masz setki, tysiące lub miliony klientów . Jednym z powodów jest wspomniana wyżej ortogonalność, innym jest buforowanie, które otrzymujesz za darmo, ponieważ używasz HTTP.
SOAP może być szybszym rozwiązaniem, gdy potrzebujesz mniejszego interfejsu API dla klienta lub dwóch i nie martwisz się zbytnio skalowalnością. Może to również pasować lepiej, jeśli nie masz architektury opartej na zasobach , ponieważ może to zająć trochę czasu, aby zrestrukturyzować aplikację, aby móc nawet wdrożyć REST.
Może to być drobna kwestia, ale REST jest całkowicie oparty na HTTP.
SOAP nie wymaga HTTP i możesz swobodnie korzystać z dowolnego transportu.
Komunikaty SOAP mogą być kierowane asynchronicznie i niezawodnie, podczas gdy REST jest w zasadzie paradygmatem synchronicznym.
REST nic nie mówi o tym, jak powinny wyglądać wysyłane i odbierane dane. Istnieje WADL, ale przeważnie polegasz na poprawności dokumentacji API. SOAP ma cyrk technologii XML, dzięki czemu opis danych jest mniej podatny na błędy. WSDL, schemat ...
Na koniec dnia REST w zasadzie zapewnia system plików oparty na HTTP. Jeśli twój system pasuje do tego paradygmatu - może to być dobry wybór.
Co zatem daje dodatkowe obciążenie / złożoność SOAP, kiedy jest to potrzebne, a kiedy można i należy bez niego?
Największą różnicą między nimi jest to, że REST ma być bezstanowy, w przeciwieństwie do SOAP . W praktyce wiele implementacji REST faktycznie implementuje pewien stan w sesji poprzez coś takiego jak OAuth.
Inną różnicą jest to, że REST jest bardzo „zorientowany na zasoby” lub rzeczownik . Korzystasz z zasobów za pomocą operacji CRUD. Wszystko, co nie pasuje do tego paradygmatu, staje się nieporęczne i niewygodne.
Z drugiej strony SOAP jest protokołem RPC (Remote Procedural Call) . Nie ma paradygmatu, to tylko warstwa transportowa.
REST również korzysta z poczty. W rzeczywistości, gdy używasz REST, czasowniki http mówią ci, co się dzieje.
REST i SOAP to po prostu różne standardy przesyłania danych przez Internet.
Korzystając z obu, ogólnie zalecałbym używanie REST zamiast SOAP, chyba że znasz osoby, które zamierzają korzystać z twojej usługi sieciowej, używają .net i Visual Studio. Zasadniczo znacznie łatwiej jest korzystać z usługi internetowej REST, z wyjątkiem .net VS, który wykonuje większość pracy za Ciebie, gdy używasz SOAP.
Jedną rzeczą, o której chciałbym wspomnieć, jest interoperacyjność - jeśli zamierzasz wywołać swoją usługę z aplikacji napisanej w .NET, a serwer jest napisany w Javie (lub innej kombinacji), wybierz REST. Widziałem zbyt wiele drobnych niezgodności między implementacjami SOAP, aby męczyć się nad tym.
Jeśli potrzebujesz prostego, wizualnego przewodnika, który pomoże Ci zmierzyć SOAP i REST względem wymagań aplikacji ...
Vijay Prasad Gupta opracowała prosty, pomocny schemat blokowy.
Bezpośredni link do schematu blokowego : https://drive.google.com/file/d/0B3zMtAq1Rf-sdVFNdThvNmZWRGc/edit
Link do artykułu: https://www.linkedin.com/pulse/20140818062318-7933571-soap-vs-rest-flowchart-to-determine-the-right-web-services-protocol-for-your-needs
Jest rok 2015. Miałem nadzieję, że SOAP już zmarł, ale nadal utrzymuje się jak nieprzyjemny zapach. W przypadku niczego poza najbardziej podstawowymi „przykładowymi” aplikacjami integracja z usługą SOAP jest trudna. Jest to złożona architektura, z wieloma opcjami na wielu poziomach, w połączeniu z dziwactwami wielu implementacji i subtelnymi (i nie tak subtelnymi) niezgodnościami. Nigdy nie miałem z tym ani jednego dobrego doświadczenia. Z drugiej strony REST to pestka: każdy rozumie HTTP. W większości przypadków JSON ma o wiele większą użyteczność niż XML InfoSet.
Aby dać Ci wyobrażenie o złożoności SOAP, spróbuj zintegrować bibliotekę SOAP w swoim projekcie. W przypadku języka Java najbardziej podstawowy klient Apache Axis2 (wykorzystujący proste powiązanie danych ADB) pobiera 23 nowe pliki JAR. Dwadzieścia trzy! 20 MB wzdęcia biblioteki. CXF jest podobny: 21 JAR, kiedy ostatnio liczyłem.
Jeśli naprawdę tego chcesz, możesz wykonać REST za pomocą prostej biblioteki HTTP.