Typy API

Obecnie na rynku dostępne są różne typy API. W artykule postaram się przybliżyć czym powinniśmy się kierować przy wyborze odpowiedniego. Jakie mają zastosowania, wady i zalety.

API dla systemów operacyjnych

Gdy aplikacja potrzebuje określonych usług z systemu operacyjnego, takich jak dostęp do systemu plików lub interakcja z urządzeniami sieciowymi i elementami interfejsu użytkownika, wykorzystuje interfejs API systemu operacyjnego. Na przykład Win32 API służy jako ilustracja interfejsu API systemu operacyjnego często wykorzystywanego do tych zadań.

Biblioteki API

Gdy jedna biblioteka udostępnia funkcje z innej biblioteki, takie jak interfejs API rejestrowania, obie biblioteki istnieją w tym samym procesie. Nie komunikują się przez żadną sieć.

Zdalne API

Komponenty są rozproszone w sieci, co oznacza, że nie znajdują się w tym samym procesie i prawdopodobnie nie znajdują się na tym samym serwerze, maszynie wirtualnej lub komputerze. Aby ułatwić komunikację między nimi, muszą one przechodzić przez sieć. Oba komponenty zostaną zbudowane na tej samej platformie programistycznej.

Web API

Komunikacja odbywa się przez Internet. Ma zastosowanie na różnych platformach, systemach operacyjnych lub językach programowania. Web API odgrywają kluczową rolę we wspieraniu interoperacyjności między różnymi systemami oprogramowania i usługami w sieci. Zapewniają one znormalizowaną metodę komunikacji i wymiany danych między aplikacjami, przyczyniając się do ewolucji bardziej połączonych i zintegrowanych ekosystemów oprogramowania.

Typy Web API:

SOAP, skrót od Simple Object Access Protocol, służy jako protokół komunikacyjny stworzony do wymiany ustrukturyzowanych informacji w usługach internetowych. Zapewnia on znormalizowane podejście dla różnych systemów do komunikacji za pośrednictwem sieci, często Internetu. SOAP wykorzystuje XML (eXtensible Markup Language) jako format wiadomości i może być przesyłany przez różne protokoły, w tym HTTP, SMTP i inne.

REST – REST API (Representational State Transfer Application Programming Interface) obejmuje zasady i konwencje ułatwiające komunikację między różnymi systemami oprogramowania przez Internet. Jest zgodny z zasadami REST, wykorzystując standardowe metody HTTP, takie jak GET, POST, PUT i DELETE do wykonywania operacji na zasobach, takich jak dane lub usługi. Interfejsy API REST zwykle wymieniają dane w formatach takich jak JSON lub XML i są znane ze swojej prostoty, skalowalności i bezstanowości, dzięki czemu są szeroko stosowane w aplikacjach internetowych i mobilnych.

Struktura żądania API REST:

Metoda – Metody HTTP (GET, POST, PUT, DELETE…) URL – lokalizacja zasobu + parametry Headers – metadane żądania (User Agent…) Body – treść żądania (opcjonalnie) Struktura odpowiedzi REST API (zazwyczaj w JSON, ale może być również w XML lub HTML):

Kod statusu – 200 (Sukces), 404 (Nie znaleziono), itd…. Headers – metadane odpowiedzi (Content Type…) Body – zawartość odpowiedzi (opcjonalnie) Interfejsy API RESTful wykonują operacje CRUD (Create, Read, Update, Delete) w celu interakcji z zasobami.

Podstawowe metody API REST:

GET: Pobieranie zasobu. POST: Służy do dodawania zasobu. Powinien zawierać treść wiadomości określającą zasób, który ma zostać dodany i nie powinien zawierać parametrów ciągu zapytania. PUT: Służy do modyfikowania zasobów. Powinien zawierać treść wiadomości określającą zasób, który ma zostać zmodyfikowany i nie powinien zawierać parametrów ciągu zapytania. DELETE: Wdrażany w celu usunięcia zasobu, w połączeniu z parametrem. Nie powinien zawierać treści komunikatu.

Graph 1.0 Struktura adresu URL interfejsu API REST.

GraphQL

to współczesny język zapytań i środowisko wykonawcze dla interfejsów API, stanowiące bardziej efektywną, solidną i elastyczną alternatywę dla tradycyjnych interfejsów API REST. W przeciwieństwie do stałych punktów końcowych i odpowiedzi, GraphQL umożliwia klientom żądanie wyłącznie wymaganych danych i otrzymywanie ich w ustrukturyzowanym formacie. Początkowo opracowany przez Facebooka, przekształcił się w projekt open-source. GraphQL działa na JSON, gdzie zapytania i dane są przesyłane w formacie JSON.

GraphQL obsługuje trzy kategorie operacji: pobieranie danych, zapisywanie/modyfikowanie danych oraz subskrybowanie zmian w danych. Działa na schemacie, wykorzystując predefiniowaną strukturę, która określa jednostki, pola i atrybuty. Operacje są formułowane zgodnie z tym schematem. Klienci i serwery mogą być budowane na różnych platformach, z wieloma implementacjami dostępnymi w różnych środowiskach.

Angażowanie się w GraphQL obejmuje następujące kroki: \ Określenie schematu. \ Tworzenie zapytań. \ Tworzenie mutacji i subskrypcji (opcjonalnie). Wdrażanie logiki.

Schemat jest wykorzystywany do: \ Definiowanie struktury danych. definiowania zapytań definiowania mutacji Definiowanie subskrypcji.

gRPC

odnosi się do ograniczeń REST, w tym ograniczeń wydajności, polegania wyłącznie na interakcjach żądanie-odpowiedź i ograniczonej składni. Firmy są zmotywowane do zbadania alternatywnych implementacji API z powodu napotkanych problemów z interfejsami API REST.

gRPC, skrót od gRPC Remote Procedure Call, wyróżnia się jako framework open-source opracowany przez Google w celu tworzenia wydajnych i skalowalnych systemów rozproszonych. Wykorzystuje on protokół HTTP/2 do komunikacji i Protocol Buffers (protobuf) jako język opisu interfejsu.

W 2015 roku Google strategicznie zdecydowało się opracować kolejną iterację Stubby, wprowadzając ją do społeczności open-source jako gRPC. Komunikacja w gRPC jest dwukierunkowa przez HTTP, w szczególności opierając się na protokole HTTP/2 w celu przezwyciężenia różnych wyzwań związanych z wydajnością, z kluczowym naciskiem na połączenie klient-serwer.

Mocną stroną gRPC jest obsługa dwukierunkowego przesyłania strumieniowego, umożliwiająca zarówno klientowi, jak i serwerowi wymianę strumieni komunikatów. Funkcja ta okazuje się bardzo korzystna w scenariuszach wymagających aktualizacji w czasie rzeczywistym.

Chociaż gRPC jest często kojarzony z komunikacją serwer-serwer ze względu na zaawansowaną obsługę protokołu HTTP/2, jego zasięg rozciąga się na przeglądarki internetowe dzięki dostępności bibliotek klienckich. Pomimo tego, gRPC jest szeroko wykorzystywany w natywnych aplikacjach mobilnych i systemach zaplecza.

W gRPC klient może wykonywać określone metody na serwerze, oferując unikalne podejście w porównaniu do REST, który zajmuje się głównie encjami.

W gRPC klient może wykonać określoną metodę na serwerze. W przeciwieństwie do tego, REST działa głównie z encjami.

Protocol Buffers

często określany jako protobuf, reprezentuje metodologię opracowaną przez Google do serializacji danych strukturalnych. Zapewnia on niezależny od języka format kodowania danych, przewyższający XML lub JSON pod względem wydajności i zwartości. Bufory protokołów są szeroko stosowane w komunikacji między systemami, szczególnie w sytuacjach, w których wydajność i rozmiar danych mają ogromne znaczenie.

gRPC wyróżnia się solidnymi możliwościami obsługi błędów. W przeciwieństwie do REST, nie zależy on od wbudowanych błędów HTTP. W przypadku wystąpienia błędu w gRPC, zwraca on kod statusu, który oznacza charakter błędu, wraz z odpowiednimi dodatkowymi informacjami.

Ostateczny werdykt

Wybór między REST API, GraphQL i gRPC zależy od różnych czynników, w tym wymagań projektu, wiedzy zespołu programistów i charakteru tworzonej aplikacji. Oto rozważania dotyczące każdego z nich:

REST API:

Operacje skoncentrowane na zasobach: Jeśli aplikacja koncentruje się na operacjach skoncentrowanych na zasobach i funkcjonalności CRUD (Create, Read, Update, Delete). Prostota i znajomość: Gdy prostota i znajomość mają kluczowe znaczenie, zwłaszcza w przypadku małych i średnich projektów. Bezstanowość: Jeśli bezstanowość jest podstawowym wymogiem dla aplikacji.

GraphQL:

Elastyczne zapytania: Jeśli aplikacja wymaga elastycznych i zoptymalizowanych zapytań o dane, umożliwiając klientom żądanie tylko niezbędnych danych. Pojedyncze żądanie dla wielu zasobów: W celu ograniczenia nadmiernego lub niedostatecznego pobierania danych poprzez umożliwienie klientom żądania wielu zasobów w jednym zapytaniu. Potrzeby w zakresie danych w czasie rzeczywistym: Dla scenariuszy, w których niezbędne są aktualizacje danych w czasie rzeczywistym lub modele subskrypcji.

gRPC:

Wydajność i efektywność: Jeśli wydajność i efektywność są najważniejsze, zwłaszcza w architekturach mikrousług lub w przypadku systemów rozproszonych na dużą skalę. Silne typowanie: Gdy silnie typowany system z jasnymi definicjami kontraktów ma kluczowe znaczenie dla aplikacji. Dwukierunkowe przesyłanie strumieniowe: W przypadku scenariuszy, w których konieczne jest dwukierunkowe przesyłanie strumieniowe i komunikacja w czasie rzeczywistym między klientem a serwerem.

Podsumowanie

W niektórych przypadkach odpowiednie może okazać się podejście hybrydowe obejmujące połączenie tych technologii, takie jak wykorzystanie REST dla niektórych aspektów aplikacji i zastosowanie GraphQL lub gRPC dla określonych funkcji, w których widoczne są ich mocne strony. Ostatecznie decyzja zależy od konkretnych wymagań i celów projektu.

Referencje

• www.udemy.com
• www.grpc.io
• www.graphql.org
• www.mobilelive.medium.com