REST vs SOAP?
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ą metodom 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:
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.
„Odpowiadają
metodom, a nie metodą 🙂
POST, GET, PUT i DELETE. REST „
Poprawione, dzięki!
fajny artykuł, przemyślany
Bardzo Ci dziękuję za ten art. Pomógł mi zrozumieć naturę i różnice pomiędzy SOAP / REST.
Dziękuje za feedback. Właśnie taki był cel tego posta.