SOAP to protokół wymiany danych, który został pierwszym rozpoznawalnym sposobem komunikacji usług. Jest nadal szeroko stosowany, jednak popularności bardzo ustąpił na rzecz stylu architektonicznego REST. Podobnych rozwiązań, które służą do komunikacji usług powstaje coraz więcej, a wśród nich GraphQL.
W tym artykule przybliżę Ci krótką charakterystykę dla każdego z tych trzech podejść, oraz porównam je wskazując zasadnicze różnice.
SOAP – czym jest?
SOAP pozwala na komunikacje serwisów z wykorzystaniem ustandaryzowanego kontraktu WSDL – Web Services Description Language. Innymi słowy na podstawie dostarczanego kontraktu klienci wiedzą w jaki sposób się komunikować z jego usługami. Same komunikaty są przesyłane w postaci XML.
SOAP niesie za sobą duży poziom skomplikowania przez co jest niechętnie wykorzystany. Dodatkowo przesyłanie komunikatów XML jest często nazywane „ciężkie” ze względu na mnogość znaczników, które są przesyłane po sieci.
Ponieważ SOAP jest protokołem to umożliwia on znacznie więcej możliwości m.in. możliwość szyfrowania.
SOAP Web Service
Jeśli chcesz zobaczyć jak wygląda implementacja usługi webowej opartej o SOAP w Spring Boot, to odsyłam Cię do mojego krótkiego wideo:
REST – styl architektoniczny
REST stanowi rozwiązanie, które szybko podbiło serca wielu programistów. Przede wszystkim jest on łatwy w implementacji i elastyczny pod względem doboru wymiany komunikatów. Programista ma możliwość wyboru czy chce dane przesyłać z wykorzystaniem ciężkich XML, czy lekkich obiektów JSON.
Należy pamiętać, że REST to tylko styl architektoniczny, a nie protokół. Dlatego musimy zadbać o wiele dodatkowych rzeczy takich jak np. dokumentacja dla usług. Niestety inaczej konsument nie będzie widział jak z nich skorzystać. Niemniej na te potrzeby stosuje się narzędzia dokumentujące REST API np. Swagger.
Kolejną rzeczą jest bezpieczeństwo. REST nie zapewnia szyfrowania (co w odróżnieniu realizuje SOAP). Chociaż jest to również do osiągnięcia przy wdrożeniu dodatkowo HTTPS i podpisów cyfrowych.
REST API – implementacja
W moim materiale wideo zobaczysz również jak zaimplementować CRUD REST API i wdrożyć usługę na platformę chmurową.
GraphQL – query language
GraphQL to język zapytań dla API, który został opracowany w głównej mierze przez Facebook. Jest to stosunkowo młode rozwiązanie, które funkcjonuje od 2018, jednak już udało się mu uzyskać uznanie na rynku.
GraphQL rzuca nowe światło na podejście tworzenia usług sieciowych, które udostępniają API. Swoimi elastycznymi formułami sprawia, że jest dużo dynamiczniejszy i bardziej intuicyjny niż REST. Ponadto stały endpoint czyni z aplikacji mniej skomplikowaną, a dokumentacja nie odgrywa niezbędnej roli. Dodatkowo na ogromny plus zasługuje wykonanie – w ramach jednego żądania można realizować wiele podzapytań co przekłada się na większą wydajność, oraz zmniejszenie ruchu sieciowego.
Więcej informacji na temat zasad działania tego rozwiązania dowiesz dowiesz się z mojego artykułu Nowy następca REST? Poznaj GraphQL!
GraphQL – jak tworzyć własne usługi?
Pierwsze kroki wskazujące Ci jak tworzyć rozwiązania oparte na GraphQL z wykorzystaniem Spring Boot zobaczysz w moim krótkim szkoleniu:
SOAP, REST czy GraphQL
Chociaż wszystkie rozwiązania ciężko ze sobą porównywać ponieważ każde z nich reprezentuje osobną koncepcje, to postarałem się jednak zestawić ich charakterystyczne cechy.
SOAP | REST | GraphQL | |
Czym jest? | Protokół | Styl architektoniczny | Język zapytań |
Powstał w | 1997 | 2000 | 2018 |
Czy jest bezstanowy? | Nie | Tak | Tak |
Umożliwia cachowanie? | Nie | Tak | Nie |
Reprezentacja komunikatu | XML | XML/JSON | XML/JSON |
Zapewnia szyfrowanie | Tak | Nie | Nie |
Dokumentacja | Definiowana przez WSDL | Wymaga dodatkowej implementacji | Dostępna w ramach rozwiązania |
Elastyczność | Niska | Średnia | Wysoka |
Trudność implementacji | Wysoka | Niska | Średnia |
Wniosek?
Wszystkie rozwiązania na rynku mają się dobrze. Chociaż dużo osób życzyło by odejścia w niepamięć SOAP’owi. Tak więc REST na ten moment wydaje się podejściem najczęściej praktykowanym, gdyż GraphQL uznawany jest za rozwiązanie przyszłościowe jednak kontrowersyjne.
Trzeba mieć świadomość, że REST został zaprojektowany z myślą o przyszłości, natomiast GraphQL został zaprojektowany z myślą o wydajności. Jednak sam SOAP został zaprojektowany z ówczesnymi na jego lata możliwościami i dawnym postrzeganiem rozwoju usług sieciowych 🙃
O co Twoim zdaniem powianiem dodatkowa wzbogacić tabelę, aby dawała ona jeszcze większy obraz zestawienia tych technologi?