Różnice między interfejsami API a przesyłaniem wiadomości w kontekście komunikacji aplikacji

Phil Wilkins | popularyzator i twórca rozwiązań chmurowych w Oracle | grudzień 2022 r.

Oprogramowanie musi się komunikować z innym oprogramowaniem. Czasami w jednej części aplikacji musi zamówić usługi lub wymienić dane z inną częścią aplikacji. Aplikacja może również zażądać usług lub wymieniać dane z inną aplikacją.

Można wyróżnić dwa typowe mechanizmy używane do tego rodzaju komunikacji: interfejsy programowania aplikacji (interfejsy API) i funkcje obsługi wiadomości.

Różnica między interfejsem API a funkcją obsługi wiadomości może być czasami myląca. Wynika to z faktu, że oba te terminy są używane w wielu niejednoznacznych znaczeniach. Termin API (application programming interface) sam w sobie ma w sumie jednoznaczne znaczenie, ale z przytoczonych poniżej przyczyn ma tych znaczeń kilka. Termin „obsługa wiadomości” (messaging) jest często używany w sposób bardzo ogólny i obejmuje niemal każdą komunikację między systemami. Wyjaśnijmy zatem, co tak naprawdę oznaczają oba te terminy.

Szczegółowa definicja interfejsów API

Ogólnie rzecz biorąc, interfejs API to umowa, która definiuje sposób, w jaki oprogramowanie może odbierać i odpowiadać na żądania usług. Umowa ta jest zawierana przez twórców oprogramowania.

Brzmi prosto? Tak właśnie jest, na jednym poziomie. W rzeczywistości znaczenie terminu „interfejs API" może się zmieniać w zależności od tematu rozmowy. Jeśli rozwiniemy ten akronim, mamy interfejs, czyli „umowę”, na mocy której oprogramowanie może wchodzić w interakcje z innym oprogramowaniem. Czasami rozmowa na temat interfejsu API skupia się na jego ogólnej definicji architektury, a czasami jest bardzo szczegółowa i określa konkretne sposoby implementacji interfejsu API przez programistów.

Niektóre książki i artykuły poświęcone interfejsowi API porównują go do drzwi, a jego charakterystykę — do charakterystyki tych drzwi. Na przykład mogą to być automatycznie otwierane drzwi do sklepu spożywczego lub superbezpieczne drzwi do skarbca bankowego. „Umowa” aplikacji, czyli charakterystyka drzwi, powinna natomiast pomóc w odpowiedzi na następujące pytania.

Do czego zasadniczo służy interfejs API? W kontekście analogii do drzwi chodzi o to, czy otwierają się automatycznie, bez konieczności zatrzymania się gościa i dotknięcia czegoś (drzwi sklepu spożywczego), czy też umożliwiają kontrolę dostępu i chronią to, co się za nimi znajduje (skarbiec bankowy)?
Jakie obciążenia (przesyłane dane) będą musiały być obsługiwane, aby oprogramowanie mogło działać? Na przykład w celu udostępnienia salda na rachunku bankowym oprogramowanie powinno otrzymać numer rachunku bankowego wraz z odpowiednią autoryzacją.
Jakie dane muszą być wymienione w celu wykonania tej usługi? Na przykład ważne jest dokładne określenie „wyglądu” poprawnego numeru rachunku bankowego i odpowiedniej autoryzacji oraz zdefiniowanie treści odpowiedzi. Szczegóły mają tutaj znaczenie, a brak jednoznaczności może prowadzić do błędów.
Jaki jest adres drzwi? Zazwyczaj oznacza to sposób utworzenia uniwersalnego identyfikatora zasobu (URI) dla danego żądania. Innymi słowy, w jaki sposób autor żądania faktycznie komunikuje się z interfejsem API?
Jakie protokoły zostaną użyte do komunikacji? Mogą to być zarówno dobrze znane protokoły, takie jak HTTP i FTP, jak i protokoły specjalne, takie jak STOMP i QUIC.
Jakich warunków musi przestrzegać użytkownik interfejsu API? Warunki te mogą dotyczyć szczegółów szyfrowania, limitu częstości wywoływania interfejsów API lub mechanizmów obciążania zwrotnego w przypadku usług komercyjnych.
Co zapewnia interfejs API? Intefejs API powinien zapewniać określony poziom usług, czyli na przykład gwarantować, że określone żądanie zostanie potwierdzone lub wykonane w określonym terminie.

Definicja funkcji obsługi wiadomości w procesie tworzenia aplikacji

O ile interfejsy API definiują sposób wysyłania i odbierania żądań usług przez oprogramowanie, o tyle obsługa wiadomości to proces wysyłania informacji z jednego systemu do drugiego. Kluczowym słowem jest tutaj „proces”.

Można to sobie zobrazować w następujący sposób:

Obsługa wiadomości oznacza proces przesyłania części informacji, tj. wiadomości, od żądającego usługi do dostawcy usługi (często za pośrednictwem osoby trzeciej, czyli brokera).

Aby posłużyć się rzeczywistą analogią, rozważmy przedsiębiorstwo wysyłające klientowi wiadomość tekstową. Usługodawca musi znać numer telefonu usługobiorcy, aby operator sieci komórkowej mógł odpowiednio przekazać wiadomość. Sam ładunek takiej wiadomości może być jednak z perspektywy operatora dowolny. Operator nie musi wiedzieć, czy przekazywana wiadomość tekstowa jest w języku angielskim, hiszpańskim, japońskim czy emoji.
Obsługa wiadomości odnosi się do wszystkich zakulisowych działań mających na celu przekazanie wiadomości od nadawcy do odbiorcy.

Ani nadawca, ani odbiorca nie muszą rozumieć zasad obsługi wiadomości, ponieważ ufają, że zarówno operatorzy sieci komórkowych, jak i producenci smartfonów dobrze wykonali swoją pracę. Podobnie operator nie musi rozumieć ładunku, ponieważ jego zadaniem jest wyłącznie dopilnowanie, aby ładunek ten został dostarczony do właściwego odbiorcy i nie był w jakikolwiek sposób zniekształcony ani zafałszowany.

Warto powtórzyć, że większość platform do obsługi wiadomości nie jest zainteresowana ładunkiem, o ile mieści się on w ograniczeniach danej technologii. Wracając do naszej analogii, smartfony i operatorzy komórkowi nie zwracają uwagi na to, czy przekazywany tekst jest w języku angielskim czy emoji.

Dowiedz się więcej o łączeniu interfejsów API, platformach API i zarządzaniu interfejsami API.

Współdziałanie interfejsów API i funkcji obsługi wiadomości w systemach przedsiębiorstw

Systemy oprogramowania korporacyjnego są budowane na bazie wielu oddzielnych procesów wykonywalnych i w rezultacie wymagają komunikacji międzyprocesowej (IPC). Komunikacja w tym przypadku może być złożona i w celu przeprowadzenia transakcji wymagać wielu wymian danych związanych z licznymi wywołaniami interfejsu API z dużą ilością odpowiednio sformatowanych danych. Transakcje te muszą być starannie zorkiestrowane i wykonane w odpowiedniej kolejności, aby zaspokoić konkretne potrzeby biznesowe.

Rozważmy na przykład złożone przez klienta zamówienie zakupu. Dany proces będzie zatem musiał uzyskać dostęp do bazy danych klientów; wysyłać zapytania do bazy danych zapasów, systemu księgowego, systemu generowania faktur i systemu obciążania kart kredytowych; korygować stany magazynowe i konto klienta; utworzyć wniosek do magazynu i wygenerować wniosek o wysyłkę, przy czym wszystkie te czynności będą musiały zostać wykonane we właściwej kolejności i prawidłowo zakończone.

W przeszłości interakcje te były wykonywane przy użyciu określonej formy współdzielonej pamięci masowej, na przykład systemu plików lub bazy danych. W bardziej nowoczesnych systemach dla przedsiębiorstw procesy te mogą jednak komunikować się ze sobą bezpośrednio, przyspieszając cały proces i eliminując problemy (związane na przykład z przydzieleniem zapasów do niewłaściwych zamówień).

Zachowania synchroniczne i asynchroniczne

Naszą komunikację możemy podzielić na synchroniczną i asynchroniczną. Komunikacja synchroniczna oznacza, że wszystkie strony zaangażowane w ten proces muszą być obecne i zdolne do ponownego wysłania wiadomości. W naszym przykładzie dotyczącym zamówień, systemy obsługi płatności elektronicznych muszą być dostępne użycia w czasie rzeczywistym. W innych przypadkach komunikacja może być asynchroniczna, dzięki czemu części systemów zamierzające się komunikować nie muszą być obecne w tym samym momencie. Tak samo działa to w przypadku, gdy piszemy do siebie wiadomości e-mail. Aby komunikacja działała asynchronicznie, potrzebny jest pośrednik, który umożliwi przekazywanie informacji w obie strony.

Te złożone systemy obsługi wiadomości dla przedsiębiorstw występują w różnych odmianach lub wzorach:

Magistracla usług. Magistrala usług (service bus) spaja i orkiestruje różne procesy, tak jak w przypadku złożonej transakcji wspomnianej powyżej. Systemy magistral usług zazwyczaj oferują funkcje zapewniające dodatkowe korzyści, takie jak możliwość tłumaczenia ładunków na różne formaty (z angielskiego na francuski w analogii do obsługi wiadomości tekstowych), routing wiadomości na podstawie ich treści, a nawet podejmowanie określonych decyzji na podstawie stanu złożonej transakcji. Na przykład zadania A i B mogą być wykonywane równolegle; wykonaj zadanie C, jeśli zadanie B zakończy się pomyślnie; jeśli zadanie B zakończy się niepowodzeniem, wykonaj zadanie D; jeśli zadanie D zakończy się niepowodzeniem, zaangażuj człowieka.

Obsługa wiadomości w stylu magistrali usług jest czasami określana jako korzystanie z kanału inteligentnego (smart pipe) ze względu na dodatkową inteligencję w zakresie routingu i planowania wiadomości w kanale łączącym nadawców i odbiorców. W tym kontekście używa się również terminu orkiestracja.

Nadawca wiadomości wywołuje magistralę usług, przesyłając wiadomość. Następnie magistrala usług odbiera tę wiadomość i przekierowuje ją do odbiorców. Podczas takiego przekierowania (routingu) wiadomość może podlegać logice transformacji i filtrowaniu.

Synonimem terminu magistrala usług jest magistrala wiadomości (message bus). Kiedy te technologie były rozwijane, aby utworzyć architekturę zorientowaną na usługi (SOA), istniały pewne różnice między magistralami wiadomości a magistralami usług. Obecnie nie ma między nimi żadnych istotnych różnic. W rzeczywistości termin ten jest coraz częściej skracany do samej magistrali.
Usługi WWW. W najszerszym znaczeniu tego terminu, usługi WWW zapewniają bezpośrednią synchroniczną komunikację między dwoma procesami, zazwyczaj przy użyciu protokołów TCP i HTTP (lub ich odmian, takich jak HTTPS i HTTP/2). Komunikacja między klientem a odbiorcą jest realizowana w postaci połączeń typu punkt-punkt (choć często zdarza się, że nadawca obsługuje wiele jednoczesnych połączeń z klientami). Pomiędzy tymi dwoma procesami mogą istnieć elementy pośredniczące (od zapór sieciowych po bramy interfejsów API i sieciowe pamięci podręczne) oraz elementy infrastruktury sieciowej (przełączniki i routery), ale ani nadawca, ani odbiorca nie będą świadomi ich istnienia.
Nadawca wiadomości komunikuje się bezpośrednio z odbiorcą. Proces transmisji zależy od dostępności obu stron.
Brokery wiadomości.Brokery wiadomości to elementy pośredniczące między nadawcą a odbiorcą wiadomości, które mają wspólne cechy zarówno z magistralami usług, jak i usługami WWW.

Brokery znajdują się pomiędzy nadawcą a odbiorcami wiadomości. Ich zadaniem jest odbieranie przekazywanych wiadomości i przechowywanie ich do momentu, aż odbiorcy je wykorzystają. Oznacza to, że przesyłana wiadomość dotrze do odbiorcy, nawet jeśli nie będzie on od razu dostępny. W rezultacie ten rodzaj komunikacji jest często określany jako asynchroniczny (ewentualnie „wystrzel i zapomnij”), ponieważ wiadomość na pewno zostanie w pewnym momencie dostarczona, o ile broker będzie działać.

Podobieństwo do usług WWW wynika natomiast z faktu, że połączenie między klientem a brokerem ma postać połączenia punkt-punkt; broker wiadomości jest funkcjonalnie niewidoczny.

Podobieństwo do magistrali usług wynika z faktu, że broker oferuje usługę zapewniającą dodatkowe korzyści, polegającą na tym, że może przechowywać odebrane wiadomości do czasu, aż odbiorcy będą dostępni. W przeciwieństwie do bardziej rozbudowanej magistrali usług, broker wiadomości „rozumie” jedynie proste rzeczy, na przykład wie, którzy odbiorcy mogą chcieć otrzymać daną wiadomość i co zrobić, jeśli odbiorca nie odbierze wiadomości w terminie.

Komunikacja oparta na brokerach jest określana mianem kanału nieinteligentnego (dumb pipe). Brokery mają minimalną inteligencję, dlatego punkty końcowe muszą rozumieć, co jest potrzebne, gdy wiadomość ma zostać wysłana lub odebrana. Styl ten jest określany terminem choreografia (choreography) w przeciwieństwie do bardziej inteligentnej orkiestracji magistrali usług.

Nadawca wiadomości przekazuje ją brokerowi. Następnie broker przechowuje wiadomość do momentu, gdy odbiorca (odbiorcy) albo zażąda (zażądają) tej wiadomości, albo będzie (będą) w stanie ją odebrać. Nadawca nie jest zależny od odbiorcy.

Rola przesyłania strumieniowego w obsłudze wiadomości w przedsiębiorstwie

Na potrzeby tej analizy przesyłanie strumieniowe może być postrzegane jako wyspecjalizowana forma obsługi wiadomości, chociaż niektóre technologie przesyłania strumieniowego mogą obsługiwać element przetwarzania danych. W tym kontekście przesyłanie strumieniowe opisuje czynność wysyłania nieprzerwanego ciągu zdarzeń za pośrednictwem technologii IPC do tego samego miejsca docelowego (tych samych miejsc docelowych), niezależnie od tego, czy usługi WWW lub brokery wiadomości realizują taką komunikację. (Bardzo rzadko w procesie tym wykorzystywane są magistrale usług, ponieważ dane przepływają zbyt szybko i jest ich zbyt dużo, aby dodatkowa inteligencja magistrali usług była potrzebna).

Oprócz zapewnienia nieprzerwanego przepływu danych w strumieniu, przesyłanie strumieniowe zwykle wymaga łączności w czasie zbliżonym do rzeczywistego lub o bardzo małym opóźnieniu. Nie będzie to zaskoczeniem, jeśli wziąć pod uwagę fakt, że usługi takie jak Netflix są tradycyjnie określane jako filmy przesyłane strumieniowo. Z pewnością nikt nie chce, aby filmy się zatrzymywały w oczekiwaniu na kolejne fragmenty danych przesyłane przez nadawcę lub gdy broker wiadomości konwertuje dane wideo z jednego formatu na inny.

Popularne technologie przesyłania strumieniowego usług WWW to WebSockets, strumienie gRPC i subskrypcje GraphQL. Jeśli chodzi o oparte na brokerach przesyłanie strumieni wiadomości (przy użyciu technologii takich jak Kafka), można czasami wykorzystać sposób działania brokera, aby przeanalizować fragment przesyłanych zdarzeń. Pomaga to w zbieraniu cennych informacji, w tym informacji o samym strumieniu (stąd termin analityka przesyłania strumieniowego).

O ile mająca zastosowanie w analityce przesyłania strumieniowego logika może być złożona, o tyle broker wiadomości nie podejmuje decyzji ani nie manipuluje wiadomościami. Z tego względu jest uważany za pozbawiony inteligencji. Tego rodzaju funkcje analityki strumieniowej są często wdrażane z wykorzystaniem technologii takich jak Kafka Streams.

Standardy branżowe w zakresie interfejsów API i obsługi wiadomości

Interfejsy API i systemy obsługi wiadomości są łatwe do opisania, ale bardzo złożone w szczegółach i charakterystyce technicznej. Nie ma tu po prostu miejsca na niejasności, co prowadzi do rzeczywistego zapotrzebowania na precyzyjne standardy branżowe i dokumenty techniczne oraz jak najlepsze zastosowanie tych standardów.

Jest to obszar rozwijany, szczególnie w przypadku interfejsów API, od ponad dekady. Branża przyjęła specyfikację OpenAPI dla interfejsów API opartych na protokole REST, które są formą usług WWW i prawdopodobnie najpopularniejszymi typami interfejsów API używanymi w nowoczesnym oprogramowaniu dla przedsiębiorstw.

W przypadku interfejsów API (i przesyłania strumieniowego) istnieje szereg dodatkowych standardów definiowania i opisywania aspektów wiadomości i przesyłania wiadomości. Standardy te to m.in. bufory protokołów (nazywane również Protobuf i używane z gRPC), a od niedawna także GraphQL, JSON Schema i YAML.

W ciągu ostatnich kilku lat w dziedzinie asynchronicznej obsługi wiadomości podjęto udane działania na rzecz przyjęcia wspólnej definicji o nazwie AsyncAPI, która adaptuje koncepcje ze standardu OpenAPI i innych rozwijanych standardów w celu zaspokojenia różnych wymagań związanych z obsługą wiadomości.

Nowoczesne aplikacje rozproszone są wdrażane jako zbiór usług będących oddzielnymi elementami oprogramowania, czasami działającymi na tych samych serwerach, a czasami nie. Interfejsy API zapewniają komunikację między tymi elementami oprogramowania, umożliwiając im wymianę informacji lub przekazywanie sobie nawzajem żądań świadczenia usług. Systemy obsługi wiadomości zapewniają infrastrukturę ułatwiającą komunikację asynchroniczną i inteligentne elementy pośredniczące dla wywołań interfejsów API, które mogą być bardzo proste (sposób działania wiadomości tekstowych na smartfonie) lub niezwykle złożone (takie jak orkiestracja złożonych wieloetapowych transakcji biznesowych). Nie wspominając już o rozproszonych usługach komunikujących się bezpośrednio ze sobą za pomocą interfejsów API. Na szczęście rozwijające się techniki i standardy pozwalają na wykorzystanie interfejsów API we wszystkich rodzajach zastosowań, od wywołań baz danych po przesyłanie strumieniowe multimediów. Wspomniana ewolucja interfejsów API i standardów obsługi wiadomości sprawia, że przejście na nowoczesną architekturę oprogramowania rozproszonego jest szybsze, łatwiejsze i bezpieczniejsze.