SOAP vs REST (różnice)

Niestety, istnieje wiele błędnych informacji i błędnych przekonań wokół REST. Nie tylko twoje pytanie i odpowiedź @cmd odzwierciedlają je, ale większość pytań i odpowiedzi związanych z tym tematem na Stack Overflow. SOAP i REST nie mogą'być porównywane bezpośrednio, ponieważ pierwszy jest protokołem (lub przynajmniej stara się być), a drugi jest stylem architektonicznym. Jest to prawdopodobnie jedno ze źródeł zamieszania wokół niego, ponieważ ludzie mają tendencję do nazywania REST każdym HTTP API, który nie jest'SOAP. Popychając rzeczy trochę i próbując ustalić porównanie, główną różnicą między SOAP i REST jest stopień sprzężenia między implementacjami klienta i serwera. Klient SOAP działa jak niestandardowa aplikacja desktopowa, ściśle powiązana z serwerem. Istnieje sztywny kontrakt między klientem a serwerem, a wszystko ma się zepsuć, jeśli któraś ze stron coś zmieni. Potrzebujesz ciągłych aktualizacji po każdej zmianie, ale łatwiej jest sprawdzić, czy umowa jest przestrzegana. Klient REST jest bardziej podobny do przeglądarki. Jest to ogólny klient, który wie, jak używać protokołu i standardowych metod, a aplikacja musi się w nim zmieścić. Nie naruszasz standardów protokołu poprzez tworzenie dodatkowych metod, ale wykorzystujesz standardowe metody i tworzysz akcje z nimi na swoim typie mediów. Jeśli jest to zrobione dobrze, jest mniej sprzężenia, a zmiany mogą być traktowane z większym wdziękiem. Klient ma wejść do usługi REST z zerową wiedzą na temat API, z wyjątkiem punktu wejścia i typu mediów. W SOAP, klient potrzebuje wcześniejszej wiedzy na temat wszystkiego, czego będzie używał, albo nawet nie rozpocznie interakcji. Dodatkowo, klient REST może być rozszerzony przez kod na żądanie dostarczony przez sam serwer, klasycznym przykładem jest kod JavaScript używany do kierowania interakcją z inną usługą po stronie klienta. Myślę, że są to kluczowe punkty, aby zrozumieć, o co chodzi w REST i jak różni się od SOAP:

• REST jest niezależny od protokołu. Nie jest sprzężony z protokołem HTTP. Podobnie jak można podążać za linkiem ftp na stronie internetowej, aplikacja REST może używać dowolnego protokołu, dla którego istnieje standardowy schemat URI.
• REST nie jest odwzorowaniem CRUD na metody HTTP. Przeczytaj tę odpowiedź, aby uzyskać szczegółowe wyjaśnienie na ten temat.
• REST jest tak ustandaryzowany, jak części, których używasz'y. Bezpieczeństwo i uwierzytelnianie w HTTP są znormalizowane, więc to's co używasz podczas robienia REST przez HTTP.
• REST nie jest REST-em bez hipermediów i HATEOAS. Oznacza to, że klient zna tylko URI punktu wejścia, a zasoby mają zwracać linki, za którymi klient powinien podążać. Te wymyślne generatory dokumentacji, które podają wzorce URI dla wszystkiego, co można zrobić w REST API, całkowicie mijają się z celem. Nie tylko dokumentują coś, co'ma być zgodne ze standardem, ale kiedy to robisz,'sprzęgasz klienta z jednym konkretnym momentem w ewolucji API, a wszelkie zmiany w API muszą być udokumentowane i zastosowane, albo się zepsują.
• REST jest stylem architektonicznym samej sieci. Kiedy wchodzisz na Stack Overflow, wiesz, czym jest użytkownik, pytanie i odpowiedź, znasz typy mediów, a strona zapewnia ci linki do nich. API REST musi robić to samo. Jeśli zaprojektowalibyśmy sieć w sposób, w jaki ludzie myślą, że REST powinien być zrobiony, zamiast strony głównej z linkami do pytań i odpowiedzi, mielibyśmy statyczną dokumentację wyjaśniającą, że aby zobaczyć pytanie, musisz wziąć URI stackoverflow.com/questions/<id>, zamienić id na Question.id i wkleić to do przeglądarki. To nonsens, ale to właśnie wiele osób uważa, że REST jest. Ten ostatni punkt nie może'być wystarczająco podkreślony. Jeśli Twoi klienci budują URI z szablonów w dokumentacji i nie dostają linków w reprezentacjach zasobów, to nie jest to REST. Roy Fielding, autor REST, wyraźnie zaznaczył to w tym wpisie na blogu: REST APIs must be hypertext-driven. Mając powyższe na uwadze, zdajesz sobie sprawę, że podczas gdy REST może nie być ograniczony do XML, aby zrobić to poprawnie z każdym innym formatem, będziesz musiał zaprojektować i ustandaryzować jakiś format dla swoich linków. Hiperłącza są standardem w XML, ale nie w JSON. Istnieją projekty standardów dla JSON, takie jak HAL. Wreszcie, REST nie jest dla wszystkich, a dowodem na to jest to, jak większość ludzi rozwiązuje swoje problemy bardzo dobrze z interfejsami API HTTP, które błędnie nazwali REST i nigdy nie zapuszczają się poza to. REST jest czasem trudny do zrobienia, szczególnie na początku, ale z czasem zwraca się z łatwiejszą ewolucją po stronie serwera i odpornością klienta na zmiany. Jeśli potrzebujesz czegoś zrobić szybko i łatwo, nie zawracaj sobie głowy REST-em. To prawdopodobnie nie jest to, czego szukasz. Jeśli potrzebujesz czegoś, co będzie musiało pozostać w sieci przez lata lub nawet dekady, to REST jest dla Ciebie.

REST vs SOAP jest nie właściwym pytaniem do zadania.

REST, w przeciwieństwie doSOAP` jest nie protokołem.

REST` jest stylem architektonicznym i projektem dla sieciowych architektur oprogramowania.

Koncepcje REST są określane jako zasoby. Reprezentacja zasobu musi być bezstanowa. Jest on reprezentowany przez pewien typ mediów. Niektóre przykłady typów mediów to XML, JSON i RDF. Zasoby są manipulowane przez komponenty. Komponenty żądają i manipulują zasobami poprzez standardowy, jednolity interfejs. W przypadku HTTP, interfejs ten składa się ze standardowych operacji HTTP np. GET, PUT, POST, DELETE.

Pytanie @Abdulaziz's oświetla fakt, że REST i HTTP są często używane w tandemie. Wynika to przede wszystkim z prostoty HTTP i jego bardzo naturalnego odwzorowania na zasady RESTful.

Fundamentalne zasady REST

Komunikacja klient-serwer

Architektury klient-serwer mają bardzo wyraźną separację problemów. Wszystkie aplikacje zbudowane w stylu RESTful muszą być również z założenia klient-serwer.

Bezstanowość

Każde żądanie klienta do serwera wymaga, aby jego stan był w pełni reprezentowany. Serwer musi być w stanie całkowicie zrozumieć żądanie klienta bez użycia jakiegokolwiek kontekstu serwera lub stanu sesji serwera. Wynika z tego, że cały stan musi być przechowywany na kliencie.

Cacheable

Ograniczenia buforowania mogą być użyte, umożliwiając w ten sposób oznaczenie danych odpowiedzi jako buforowalne lub nie-buforowalne. Wszelkie dane oznaczone jako buforowalne mogą być ponownie użyte jako odpowiedź na to samo kolejne żądanie.

Jednolity interfejs

Wszystkie komponenty muszą współdziałać poprzez jeden jednolity interfejs. Ponieważ cała interakcja komponentów odbywa się za pośrednictwem tego interfejsu, interakcja z różnymi usługami jest bardzo prosta. Interfejs jest taki sam! Oznacza to również, że zmiany w implementacji mogą być dokonywane w izolacji. Takie zmiany nie będą miały wpływu na podstawową interakcję komponentów, ponieważ jednolity interfejs jest zawsze niezmienny. Jedną wadą jest to, że utknąłeś z interfejsem. Jeśli optymalizacja mogłaby być dostarczona do konkretnej usługi poprzez zmianę interfejsu, masz pecha, ponieważ REST tego zabrania. Z jasnej strony jednak, REST jest zoptymalizowany dla sieci, stąd niesamowita popularność REST over HTTP!

Powyższe koncepcje stanowią cechy definiujące REST i odróżniają architekturę REST od innych architektur, takich jak usługi sieciowe. Warto zauważyć, że usługa REST jest usługą sieciową, ale usługa sieciowa niekoniecznie jest usługą REST.

Zobacz ten blog post na temat REST Design Principles, aby uzyskać więcej szczegółów na temat REST i wyżej wymienionych punktów.

EDIT: zaktualizuj treść na podstawie komentarzy.

SOAP (Simple Object Access Protocol) i REST (Representation State Transfer) oba są piękne na swój sposób. Nie będę ich więc porównywał. Zamiast tego, staram się przedstawić obraz, kiedy wolałem używać REST, a kiedy SOAP.

**Co to jest payload?

Kiedy dane są przesyłane przez Internet, każda przesyłana jednostka zawiera zarówno informacje nagłówkowe, jak i rzeczywiste przesyłane dane. Nagłówek identyfikuje źródło i cel pakietu, podczas gdy rzeczywiste dane są określane jako payload. Ogólnie rzecz biorąc, ładunek jest to dane, które są przenoszone w imieniu aplikacji i dane odbierane przez system docelowy.

Teraz, na przykład, muszę wysłać telegram i wszyscy wiemy, że koszt telegramu będzie zależał od kilku słów.

*Powiedz mi więc, która z tych dwóch wiadomości jest tańsza do wysłania?

<name>Arin</name>

lub

"name": "Arin"

Wiem, że twoją odpowiedzią będzie ta druga, chociaż obie reprezentują tę samą wiadomość, druga jest tańsza pod względem kosztów.

Próbuję więc powiedzieć, że wysyłanie danych przez sieć w formacie JSON jest tańsze niż wysyłanie ich w formacie XML pod względem ładunku.

To jest pierwsza korzyść lub przewaga REST nad SOAP. SOAP obsługuje tylko XML, podczas gdy REST obsługuje różne formaty, takie jak tekst, JSON, XML, itd. A wiemy już, że jeśli użyjemy Json to zdecydowanie będziemy w lepszym miejscu jeśli chodzi o payload.

Teraz SOAP obsługuje tylko XML, ale ma też swoje zalety.

**Naprawdę! Jak?

SOAP opiera się na XML-u na trzy sposoby Koperta - która definiuje co jest w wiadomości i jak ją przetworzyć.

Zestaw reguł kodowania dla typów danych, i wreszcie układ wywołań procedur i zebranych odpowiedzi.

Koperta ta jest wysyłana przez transport (HTTP/HTTPS), po czym wykonywane jest RPC (Remote Procedure Call), a koperta jest zwracana z informacjami w postaci dokumentu w formacie XML.

Ważne jest to, że jedną z zalet SOAP jest użycie "ogólnego" transportu, ale REST używa HTTP/HTTPS. SOAP może użyć prawie każdego transportu do wysłania żądania, ale REST nie może. Więc tutaj mamy zaletę używania SOAP.

Jak już wspomniałem w powyższym akapicie "REST używa HTTP/HTTPS ", więc zagłębmy się nieco w te słowa.

Kiedy mówimy o REST over HTTP, wszystkie zabezpieczenia stosowane w HTTP są dziedziczone, a to jest znane jako transport level security i zabezpiecza wiadomości tylko wtedy, kiedy są w kablu, ale kiedy już dostarczymy je na drugą stronę, nie wiemy przez ile etapów będą musiały przejść zanim dotrą do prawdziwego punktu, gdzie dane zostaną przetworzone. I oczywiście, wszystkie te etapy mogą wykorzystywać coś innego niż HTTP.**Więc Rest nie jest całkowicie bezpieczny, prawda?

Ale SOAP obsługuje SSL tak samo jak REST, dodatkowo obsługuje WS-Security, który dodaje pewne cechy bezpieczeństwa dla przedsiębiorstw. WS-Security oferuje ochronę od tworzenia wiadomości do jej konsumpcji. Tak więc dla bezpieczeństwa na poziomie transportu jakakolwiek luka, którą znaleźliśmy może zostać wyeliminowana przy użyciu WS-Security.

Poza tym, jako że REST jest ograniczony przez swój'protokół HTTP, jego obsługa transakcji nie jest ani zgodna z ACID, ani nie może zapewnić dwufazowego commitu w rozproszonych, międzynarodowych zasobach.

Natomiast SOAP posiada wszechstronne wsparcie zarówno dla zarządzania transakcjami opartego na ACID dla transakcji krótkotrwałych, jak i dla zarządzania transakcjami opartego na kompensacji dla transakcji długotrwałych. Obsługuje również dwufazowe zatwierdzanie przez rozproszone zasoby.

Nie wyciągam żadnych wniosków, ale będę preferował usługi sieciowe oparte na SOAP, gdy bezpieczeństwo, transakcje itp. są głównymi problemami.

Oto "The Java EE 6 Tutorial" gdzie powiedzieli A RESTful design may be appropriate when the following conditions are met. Spójrz.

Mam nadzieję, że podobało ci się czytanie mojej odpowiedzi.