Z artykułu dowiesz się:

Protokół komunikacyjny SOAP

To wszechstronny styl architektoniczny API, który umożliwia aplikacjom przekazywanie wiadomości. Co ciekawe, mogą być one napisane w różnych językach. Do komunikacji SOAP wykorzystuje XML, a więc jest to wyjątkowo złożone i szczegółowe API. Jego działanie bazuje na relacji klient-serwer, czyli klient wysyła zapytanie HTTP, z kolei serwer „odpowiada” na nie, udzielając mu stosowanych informacji. Każde takie zapytanie składa się z trzech części. Są to: nagłówek, komunikat i stopka.

SOAP doceniany jest w znaczącym stopniu za wysoki poziom bezpieczeństwa. Używa protokołu bazowego WS-Security, który odpowiada za bezpieczeństwo aplikacji na poziomie przedsiębiorstwa, ale również do komunikacji ze starszymi systemami. Protokół SOAP obsługuje podpisywanie cyfrowe wiadomości, dzięki czemu możliwa jest szybka weryfikacja przesyłanych wiadomości. Możliwe jest także szyfrowanie danych, co pozwala na tworzenie poufnych wiadomości. Poza tym protokół obsługuje mechanizm uwierzytelniania, dzięki czemu możliwe jest sprawdzenie tożsamości stron wysyłających i odbierających wiadomości.

Ten styl architektoniczny API to dobry wybór ze względu na:

• Wysoki poziom bezpieczeństwa – dane w wiadomościach są szyfrowane, co przekłada się na ich poufność
• Możliwość komunikacji pomiędzy różnymi platformami i językami programowania – bez problemu aplikacje stworzone w innych technologiach mogą się ze sobą wymieniać informacjami
• Elastyczność – SOAP pozwala na dodawanie wielu dodatkowych funkcji, świetnie się sprawdza w bardziej zaawansowanych projektach. Oprócz tego nie jest on związany z żadnym protokołem transportowym, co przekłada się na większą swobodę jego wyboru

SOAP ze względu na swój wysoki poziom bezpieczeństwo i wszechstronność znalazł swoje zastosowanie m.in. w usługach finansowych i bramkach płatniczych. Jest stosowany tam, gdzie kluczową rolę odgrywa poufność danych.

RESTful API, czyli internetowy weteran

Absolutnym przeciwieństwem skomplikowanej struktury SOAP jest RESTful API, styl architektoniczny, który zasłynął dzięki swojej prostocie i jednocześnie dużej elastyczności. Wykorzystuje metodę HTTP jako podstawowy sposób komunikacji. W architekturze RESTful implementacja klienta i serwera może odbywać się niezależnie, co w praktyce oznacza możliwość zmiany kodu po jednej stronie bez wpływu na drugą. Taka separacja pozwala na niezależną ewolucję klienta i serwera. Oddzielenie ich od siebie skutkuje również poprawą skalowalności na skutek uproszczenia komponentów serwera.

RESTful API jest bezstanowy, czyli stan konieczny do obsługi jest obecny w żądaniu klienta. Serwer nie przechowuje żadnej informacji o stanie, ale może przesyłać go do klienta w zmodyfikowanej wersji. Informacja o stanie musi być więc za każdym razem przesyłana przez klienta. Nie ma konieczności zarządzania sesjami klientów, co potęguje bardzo dobrą skalowalność systemów.

Przez ten interfejs API obsługiwanych jest większość usług internetowych. Korzystają z niego m.in. YouTube i Twitter, a więc mamy z nim do czynienia praktycznie codziennie. Jak każdy styl architektoniczny ma jednak swoje ograniczenia. Nie sprawdzi się najlepiej, jeśli jest zapotrzebowanie na dane w czasie rzeczywistym.

GraphQL, czyli API od Facebooka

Jeśli coś już istniejącego się nie sprawdza, to najlepiej stworzyć dla tego alternatywę samemu. Tak właśnie postąpił Facebook, który korzystał początkowo z REST API. Skutek tego był taki, że newsfeed kierował zapytania do wielu endpointów w celu pozyskania wszystkich niezbędnych danych. Jednocześnie ładowały się inne dane, które nie były istotne dla newsfeeda. To skutkowało dodatkową pracą dla inżynierów, który musieli analizować zebrane dane, chcąc znaleźć te właściwe.

Facebook zdecydował się usprawnić ten proces i stworzył własny styl architektoniczny GraphQL, który jest jednocześnie językiem zapytań. To spowodowało, że wszystkie żądania przychodzące ostatecznie trafiają do jednego punktu końcowego, po czym są pobierane, a zwracane są tylko te żądane dane. Kod źródłowy GraphQL dodatkowo został przez Facebook udostępniony jako specyfikacja i tym samym może być zaimplementowany w dowolnym języku.

GraphQL API cechuje się też łatwą skalowalnością klienta. Chcąc zmienić aplikację frontendową, nie trzeba martwić się o zapytania do API. Pozostaje jedynie dodać lub zmodyfikować query. Dzięki uporządkowanym danym i wysyłaniu tylko tych, które są nam rzeczywiście potrzebne, udało się osiągnąć wydajniejszą komunikację i szybsze odpowiedzi. Przełożyło się to na lepszą pracę oprogramowania na urządzeniach mobilnych.

Nie zawsze jednak to, co wyjątkowo elastyczne i złożone sprawdza się w każdym projekcie. GraphQL nie będzie najlepszym wyborem do prostych i małych systemów. Za to świetnie się sprawdza przy prawdziwych gigantach z dużą różnorodnością danych do pobierania, jak np. GitHub czy też Shopify.

gRPC, czyli architektura mikrousługowa

Kolejne API to dzieło Google, które przez wiele lat miało trudności z logowaniem, autoryzacją czy uwierzytelnianiem. Programiści Google opracowali więc wyjątkowo wydajny framework RPC – gRPC. Pozwala on na łączenie wiele usług w jednym środowisku danych. Oprócz tego jednak usługi mogą być łączone pomiędzy wieloma ośrodkami. Takie rozwiązanie korzystnie wpłynęło na uwierzytelnianie czy też monitorowanie. Ostatecznie obsługa w systemach rozproszonych jest dzięki gRPC tak samo efektywna i prosta, jak dzieje się to w przypadku systemów lokalnych.

Klient i serwer gRPC mogą się ze sobą komunikować niezależnie od tego, w jakim języku zostały napisane. Jako domyślny język definiujący wykorzystano w tej architekturze Protocol Buffers. Struktura danych definiowana jest jako wiadomość. Dane są zapisywane w standardowym pliku tekstowym z rozszerzeniem .proto. Wiadomości składają się z pola. Potem powstają klasy dostępu do danych w wybranym języku. Takie rozwiązanie zapewnia łatwy sposób dostępu do wszystkich pól.

Do najważniejszych zalet gRPC zaliczamy:

• Proste definiowane usług za pomocą Protocol Buffers
• Nieograniczoną skalowalność
• Łatwą instalację środowiska deweloperskiego
• Dużą wydajność
• Interoperacyjność, czyli niezależne od platformy i języka działanie
• Otwartą, dwukierunkową komunikację

gRPC świetnie sprawdza się w scenariuszach łączących nawet do kilkuset usług w środowisku lokalnym lub chmurowym. Korzysta z niego m.in. Netflix do obsługi złożonej komunikacji między usługami. Jeśli chodzi o jego ograniczenia, to nie jest to opcja dedykowana dla projektów, w których obecni są klienci przeglądarek. Wynika to z niedostatecznej obsługi przeglądarek przez gRPC.

Protokół komunikacyjny WebSocket dla stałej aktualizacji danych

WebSocket jest protokołem komunikacyjnym, który zapewnia trwałe, dwukierunkowe połączenie w czasie rzeczywistym. Pozwala na odbieranie danych bez konieczności wysyłania żądania, co jest charakterystyczne dla HTTP. Dane są stale aktualizowane po nawiązaniu połączenia. Dzieje się tak dlatego, że połączenie między klientem a serwerem pozostaje otwarte do momentu jego przerwania przez jedną ze stron. Dane w komunikatach są szyfrowane, co jest możliwe dzięki dodatkowi nad protokołem WSS. Dane są kodowane po stronie nadawcy i dekodowane przy odbiorcy. To przekłada się na ich bezpieczeństwo, przez co WebSocket jest wykorzystywany m.in. do raportów giełdowych. To także architektura dedykowana dla czatów na żywo, a także gier w czasie rzeczywistym. Tak naprawdę to dobry wybór wszędzie tam, gdzie wymagana jest wymiana danych z możliwie jak najmniejszymi opóźnieniami – chatboty, powiadomienia PUSH, platformy wymiany czy też sieci społecznościowe.

Webhook – interfejs wyzwalany przez zdarzenia

Na koniec coś odmiennego, czyli nieco inna polityka komunikacji między aplikacjami. W przeciwieństwie do innych interfejsów API, Webhook jest wyzwalany przez zdarzenia, a nie przez żądania. W praktyce wygląda to następująco:

Sklep internetowy uruchamia kampanię marketingową. Ma ona na celu pozyskanie jak najwięcej zapisów do newslettera. Kiedy użytkownik decyduje się na subskrypcję, webhook wysyła do niego powiadomienie o powodzeniu zapisu oraz kod rabatowy do wykorzystania w e-sklepie.

Webhooki są bardzo powszechnym zjawiskiem w e-commerce. Pozwalają na otrzymywanie przez aplikację danych w czasie rzeczywistym – użytkownik zapisał się do newslettera, więc można wysłać do niego wiadomość. Korzysta z nich m.in. GitHub do powiadamiania innych systemów o każdym wysłaniu nowego zatwierdzenia.

Webhook odpowiada więc za rejestrację konkretnego zdarzenia, na które ma we właściwy sposób zareagować. Bazuje na sterowanych zdarzeniami wywołaniach zwrotnych HTTP i operacjach asynchronicznych. Zasada działania operacji asynchronicznych polega na tym, że aplikacja reaguje wtedy, kiedy istnieje pewność, że wymagane dane zostały skutecznie przetransportowane z gniazda bądź pliku do pamięci komputera. Webhook nie sprawdzi się więc w projektach, w których wykorzystywane są operacje synchroniczne, co wciąż jest powszechnym zjawiskiem wśród programistów. Jednak takie podejście przekłada się w znaczącym stopniu na spowolnione działanie wielu aplikacji.

Cyfryzacja opanowała naszą rzeczywistość, a sprawna komunikacja pomiędzy systemami informatycznymi nigdy wcześniej nie była tak istotna. Od niej zależy w znaczącym stopniu powodzenie wielu projektów, jak też ogólnie funkcjonowanie firmy. Wybór odpowiedniego interfejsu, czyli tak naprawdę pomostu pozwalającego na sprawną komunikację i interakcję różnych składników oprogramowania stał się jednym z priorytetów programistów. Omówiliśmy 6 stylów architektonicznych API, które wykorzystywane są najczęściej. Pamiętaj jednak, że nie są one uniwersalne i na tyle wszechstronne, że sprawdzą się w każdym projekcie.