Menu Górne
źródło: https://nordicapis.com

W internecie można znaleźć wiele informacji na temat porównania SOAP i REST. Ale czym tak właściwie jest jedno i drugie? Czy można je właściwie porównać? Czy takie porównanie ma w ogóle sens?

SOAP

Simple Object Access Protocol to protokół komunikacyjny współdziałający z dowolnym niskopoziomowym sieciowym mechanizmem transportowym (HTTP, HTTPS, SMTP, JMS, RMI). Bazuje on na języku XML, umożliwiający przekazywanie wywołań zdalnych komponentów Web Services. SOAP jest standardem W3C, którego głównym celem było zastąpienie bardziej specyficznych protokołów komunikacyjnych (RPC), których wykorzystanie może być ograniczone poprzez zapory sieciowe lub inne zabezpieczenia. Protokół ten jest stanowy i wspiera transakcje.

Komunikaty

Komunikat SOAP zawiera znaczniki takie jak: <Envelope> – otacza cały komunikat, opcjonalny znacznik <Header> – zawiera informacje nagłówkowe, <Body> – zawiera informacje o żądaniu i odpowiedzi, <Fault> – opisuje błędy, jakie wystąpiły podczas przetwarzania wywołania, również jest opcjonalny.

Dokumentacja

Do opisu funkcjonalności API stosuje się Web Services Description Language (WSDL) oraz UDDI. WSDL jest to opracowany przez Microsoft i IBM, oparty na XML język do opisu punktów dostępu do usług internetowych. W tym przypadku opisuje on dostępne metody oraz dane potrzebne do ich wywołania. Bazy danych UDDI deklarują dostępne usługi posługując się trzema poziomami opisu:

  • –  White Pages: podstawowe dane kontaktowe o dostawcy usługi, obejmujące nazwę firmy, adres, identyfikator (np. numer identyfikacji podatkowej),
  • –  Yellow Pages: lokalizacja usługi w taksonomiach kategoryzacyjnych,
  • –  Green Pages: techniczny opis usługi i jej semantyki, często też wskaźnik do plikuWSDL.

REST

Representational State Transfer jest standardem określającym zasady projektowania API gdzie akcje CRUD (create, read, update, delete) odpowiadają metodą POST, GET, PUT i DELETE. REST nie wymaga WDSL oraz UDDI, oparty jest natomiast o kilka zasad, takich jak:

1. Uniform Interface

Jednolity interfejs do komunikacji między klientem a serwerem, można go opisać 4 zasadami:
1. Intefejs oparty jest na zasobach – każdy zasób ma swój unikalny URI, jednak sposób jego reprezentacji może być różny i jest niezależny od samego zasobu np. serwer nie wysyła danych w postaci odczytanej bezpośrednio z bazy danych, ale np. jako JSON.
2. Manipulację zasobami realizuje się poprzez jego reprezentacje – po otrzymaniu reprezentacji zasobu od serwera, klient (jeśli ma do tego uprawnienia) może modyfikować czy usuwać zasoby.
3. Odpowiedzi serwera do klienta są samo opisujące się  – każda odpowiedź serwera zawiera informacje jak ją obsłużyć.
4. HATEOAS (Hypermedia as the Engine of Application State) – pomiędzy zasobami występują relacje, natomiast klient powinien móc nawigować pomiędzy nimi za pomocą tzw. hypermedia. 

2. Client-Server

Określa wyraźnie zaznaczony podział pomiędzy logiką działającą po stronie serwera oraz klienta, tak żeby edycja jednego nie wpływała na działanie drugiej „strony”.

3. Stateless

Zasada ta określa że serwer nie powinien przechowywać informacji o stanie klienta. Każde zapytanie powinno być kompletne pod kątem informacji potrzebnych do jego przetworzenia.

4. Cacheable

Api powinno wspierać cache’owanie aby poprawić wydajność. Z reguły dla operacji odczytu istnieje możliwość cache’owania danych, natomiast dla operacji modyfikacji danych nie zaleca się stosowania takiego mechanizmu.

5. Layered system

Podczas projektowania systemu należy zwrócić uwagę na to iż klient wysyłający zapytanie powinien uzyskać odpowiedź od pytanego serwera. To powinno odbywać się bez posiadania wiedzy o tym co się dzieję „pod spodem”. Na przykład w sytuacji gdy serwer odpytuje inne zewnętrzne serwery takie ja Google itp..

6. Code on demand

Jest to zasada opcjonalna która zakłada możliwość wysyłania kodu, który możemy wykonać po stronie klienta (często JavaScript).

SOAP vs REST

Na początku artykułu zadałem pytanie czy można porównać SOAP i REST? Moim zdaniem nie ma możliwości bezpośredniego porównania, ponieważ pierwszy jest protokołem, a drugi jest stylem architektonicznym. REST i SOAP pochodzą z zupełnie innych światów.
REST zajmuje się bardziej operacjami, które można wykonywać na jednostkach sieciowych. SOAP koncentruje się na zdalnym dostępie do obiektów i manipulowaniu nimi. SOAP używa XML i zapewnia zestaw funkcji, które pozwalają definiować umowy między konsumentami a dostawcami, co jest bardzo cenne w świecie biznesu. Wszystkie ograniczenia SOAP, które działają tak dobrze w świecie korporacyjnym, są nieproduktywne w otwartej sieci web. Nie używajmy SOAP w sytuacjach, w których przepustowość jest bardzo ograniczona. Musi on przekazywać informacje o obiektach i ich stanach za pomocą XML Infoset. Zazwyczaj te modele danych są serializowane jako tekstowe XML, co wymaga znacznie większej przepustowości w stosunku do REST. SOAP jest nadal w użyciu, ale w publicznych interfejsach najczęściej można spotkać REST API lub „prawie” REST API.

Internet

Moim zdaniem częste porównania wynikają z dezinformacji i nieporozumień wokół REST. Zdarza się że API restowym ktoś nazywa każde API HTTP które nie jest SOAP’em, a to błąd. Abyśmy mogli nazwać je restowym powinniśmy spełnić (moim zdaniem) przynajmniej większość z zasad opisanych powyżej. Jako że jest to styl architektoniczny nie ma jednoznacznej granicy pomiędzy serwisem restowym a nie restowym. REST to cel do którego powinniśmy dążyć projektując serwis jednak nie za wszelką cenę. Czytając artykuły porównujące REST z SOAP trafiłem na określenie że REST jest jest jak pocztówka. Pocztówka jest lekka, krótka, wystarczy spojrzeć by ją przeczytać. Natomiast SOAP porównuje się do listu w kopercie, cięższego, dłuższego, wymagającego kilku czynności by go przeczytać. Mnie jednak urzekło to porównanie:

źródło: http://formacdownload.com

Podsumowanie

Ja, jak zwykle, polecam dobrać rozwiązanie do potrzeb. Jeżeli potrzebujemy specyficznych funkcji SOAP – wybierzmy go. Z drugiej strony, jeżeli potrzebujemy prostego serwisu który nie będzie rozbudowywany, lub wiemy że będzie za jakiś czas wymieniony na inne rozwiązanie, nie budujmy na siłę API REST – będzie to sztuka dla sztuki. Znam wiele przypadków dobrze działających serwisów które nie są SOAP ani REST i spisują się w określonej sytuacji wręcz idealnie. Jeżeli natomiast chcemy zbudować rozwijalny serwis który będzie dostępny przez kilka, kilkanaście lat powinniśmy się mocno zastanowić nad zastosowaniem zasad REST. REST został zbudowany na fundamentach samej sieci Web, wykorzystując podstawowe operacje HTTP (GET, POST, itd.) I właśnie to czyni go idealnym kandydatem w dowolnej publicznej implementacji API.

Linki:

Dokument opisujący REST

Roy T. Fielding blog

O autorze

Niepoprawny optymista. 100 pomysłów na sekundę, wielbiciel nowych technologii, nie tylko z rodziny .Net. Często nosi przy sobie jabłko, takie nadgryzione... ;)

2 Comments

  1. Bardzo Ci dziękuję za ten art. Pomógł mi zrozumieć naturę i różnice pomiędzy SOAP / REST.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Możesz używać znaczników języka HTML i ich atrybutów: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Zamknij