Który wybrać do następnego projektu [2023]

W świecie interfejsów programowania aplikacji (API) często spotykamy się z dwoma głównymi podejściami: REST i gRPC. Mimo że REST od lat wiedzie prym, gRPC staje się coraz bardziej popularną i konkurencyjną alternatywą.

Zarówno REST, jak i gRPC to odmienne metody projektowania API. API pełnią rolę łącznika umożliwiającego komunikację pomiędzy różnymi usługami, które mogą tworzyć złożone systemy działające na rozmaitych komputerach lub napisane w różnych językach programowania.

Ten artykuł omawia zarówno REST, jak i gRPC, przedstawiając ich podobieństwa i różnice, a także wskazując, w jakich sytuacjach najlepiej je stosować.

Czym jest REST?

REST (Representational State Transfer), czyli Reprezentacyjny Transfer Stanu, to koncepcja architektoniczna w projektowaniu oprogramowania, która definiuje zasady wymiany danych między poszczególnymi elementami systemu. REST opiera się na powszechnie stosowanym protokole komunikacyjnym sieciowym HTTP.

API, które wykorzystują architekturę REST, są nazywane API RESTful. Z kolei usługi internetowe zbudowane zgodnie z zasadami REST, określa się mianem usług sieciowych RESTful.

Architektura REST kieruje się następującymi zasadami:

• Jednolity interfejs: Serwer powinien dostarczać dane w ustandaryzowanej formie. Dane te mogą być prezentowane w formacie odmiennym od wewnętrznej reprezentacji zasobu po stronie serwera.
• Bezstanowość: Serwer powinien realizować każde żądanie klienta indywidualnie, bez zależności od wcześniejszych żądań. Żądania klientów mogą być składane w dowolnej kolejności, a każde z nich jest traktowane niezależnie.
• System warstwowy: Wprowadzenie warstwy autoryzowanych pośredników pomiędzy serwerem a klientem. Klient może komunikować się z tymi pośrednikami i wciąż otrzymywać odpowiedzi z serwera.
• Pamięć podręczna: Niektóre odpowiedzi mogą być przechowywane u pośrednika lub klienta, co pozwala na skrócenie czasu odpowiedzi.
• Kod na żądanie: Serwery mogą tymczasowo dostosowywać lub rozszerzać funkcjonalność klienta, przesyłając kod oprogramowania.

Zalety REST

• Skalowalność: API REST słyną ze swojej skalowalności, która wynika z optymalizacji interakcji pomiędzy klientem a serwerem. Buforowanie i bezstanowość to kluczowe elementy redukujące obciążenie serwera.
• Elastyczność: API RESTful zapewniają pełną separację między klientem a serwerem. Takie podejście dzieli i upraszcza różne komponenty serwera, umożliwiając ich niezależny rozwój.
• Niezależność: Aplikacje serwerowe i klienckie mogą być tworzone w różnych językach programowania bez wpływu na strukturę API.

Zastosowania REST

• Web API
• Usługi internetowe
• Architektura mikroserwisów

Co to jest gRPC?

gRPC to platforma zdalnego wywoływania procedur (RPC), która działa w różnorodnych środowiskach. Jest to projekt open-source o wysokiej wydajności, stworzony do efektywnego łączenia usług w centrach danych i pomiędzy nimi.

Aplikacja kliencka może wywołać metodę w aplikacji serwerowej na innym komputerze, tak jakby była to metoda lokalna. W gRPC definiujemy usługę, określając metody, które mogą być zdalnie wywoływane wraz z ich parametrami i typami zwracanymi.

gRPC oferuje wbudowane funkcje kontroli stanu, uwierzytelniania, równoważenia obciążenia oraz wsparcie dla śledzenia. Wykorzystuje protokół HTTP/2 oraz bufory protokołów do przesyłania danych. Zamiast odwoływać się do URL zasobu, w gRPC wywoływana jest konkretna procedura.

Zalety gRPC

• Skalowalność: gRPC umożliwia szybkie uruchamianie środowisk wykonawczych i skalowanie do milionów wywołań RPC na sekundę.
• Prosta definicja usług: Użycie buforów protokołów upraszcza definiowanie usług.
• Wieloplatformowość: Framework ten generuje kody pośredniczące dla klienta i serwera, które są dostosowane do różnych platform i języków programowania.
• Dwukierunkowe przesyłanie strumieniowe i wbudowana autoryzacja.

Zastosowania gRPC

• Web API
• Usługi internetowe
• Aplikacje strumieniowe
• Komunikacja mikroserwisów

Podobieństwa między REST i gRPC

• Mechanizm wymiany danych: Obie architektury umożliwiają komunikację i wymianę danych między serwerami i klientami, chociaż odbywa się to na podstawie różnych zasad.
• Dostosowanie do skalowalnych systemów rozproszonych: Asynchroniczna komunikacja oraz bezstanowa natura obu podejść ułatwiają skalowanie API.
• Wykorzystanie komunikacji opartej na HTTP: Zarówno REST, jak i gRPC korzystają z protokołu HTTP, najczęściej używanego w komunikacji sieciowej.
• Elastyczność: REST i gRPC można stosować w połączeniu z różnorodnymi językami programowania i technologiami.

REST vs. gRPC: szczegółowe porównanie

Poniżej przedstawiamy kluczowe różnice między REST a gRPC:

Wymiana danych

W API REST dane przesyłane między komponentami oprogramowania muszą być reprezentowane w formacie JSON. JSON musi być zserializowany, a następnie przetłumaczony na język programowania, aby umożliwić wymianę danych. REST API może również korzystać z formatów takich jak HTML i XML.

gRPC domyślnie używa buforów protokołów. Choć natywnie obsługuje JSON, bufory protokołów nie są czytelne dla człowieka. Serwer wykorzystuje język opisu interfejsu Protocol Buffer do zdefiniowania struktury danych, która następnie jest serializowana do formatu binarnego i deserializowana na poziomie klienta.

Model komunikacji

W REST klient wysyła jedno żądanie do serwera, który w odpowiedzi przesyła odpowiedź. Klient musi zaczekać na odpowiedź serwera, zanim będzie mógł kontynuować operację. Jest to model żądanie-odpowiedź.

W gRPC klient może przesyłać jedno lub więcej żądań do serwera, co może skutkować jedną lub wieloma odpowiedziami. Połączenia danych mogą przyjmować formę: wiele-do-wielu, wiele-do-jednego, jeden-do-wielu lub jeden-do-jednego. gRPC wykorzystuje model komunikacji typu klient-serwer.

Generowanie kodu

gRPC oferuje wbudowaną funkcję generowania kodu po stronie serwera i klienta w różnych językach programowania, dzięki kompilatorowi Protocol Buffers. Kod jest generowany automatycznie na podstawie definicji struktury danych zapisanej w pliku .proto.

REST nie posiada wbudowanych mechanizmów generowania kodu i w tym celu należy korzystać z narzędzi zewnętrznych.

Protokół HTTP

API REST korzystają z protokołu HTTP 1.1. Aby wysłać żądanie, wymagany jest adres URL zasobu. Protokół HTTP/1.1 służy do przesyłania danych między komputerem a serwerem WWW. URL zasobu w REST jest widoczny dla klienta, a projektanci API kontrolują strukturę tych URL-i.

gRPC korzysta z HTTP/2, wprowadzonego w 2015 roku, który jest stosowany w popularnych przeglądarkach. W przeciwieństwie do HTTP/1.1, który przesyła dane w formie tekstowej, HTTP/2 wykorzystuje enkapsulację formatu binarnego, co przyspiesza proces i daje więcej możliwości dostarczania danych.

Struktura danych ładunku

REST używa XML lub JSON do przesyłania danych, przy czym JSON jest najczęściej stosowany ze względu na swoją elastyczność i brak konieczności definiowania struktury. JSON jest czytelny dla człowieka, jednak jego wadą jest konieczność serializacji i tłumaczenia podczas przesyłania danych, co obniża szybkość przesyłu.

gRPC wykorzystuje bufor protokołów do serializacji danych, dzięki czemu format jest wysoce skompresowany i minimalizuje objętość danych. Protobuf automatycznie konwertuje komunikaty o silnych typach na języki programowania klienta i serwera.

Obsługa przeglądarki

REST jest obsługiwany przez wszystkie przeglądarki, gdyż korzysta z HTTP/1.1. To sprawia, że jest idealny do tworzenia usług internetowych i API.

gRPC ma ograniczone wsparcie przeglądarek ze względu na wykorzystanie HTTP/2. Aby wspierać wszystkie przeglądarki, konieczne jest dodanie gRPC-web jako warstwy proxy serwera, dlatego gRPC jest najczęściej wykorzystywane w systemach wewnętrznych.

Sprzężenie klient-serwer

REST to architektura luźno sprzężona, co oznacza, że klient i serwer nie muszą mieć szczegółowej wiedzy o swojej implementacji. Ułatwia to ewolucję API RESTful, ponieważ zmiany po stronie serwera nie wymagają modyfikacji kodu klienta.

gRPC to struktura ściśle sprzężona, gdzie serwer i klient muszą mieć dostęp do tego samego pliku .proto. Wprowadzenie jakiejkolwiek zmiany w pliku wymaga aktualizacji zarówno serwera, jak i klienta.

REST vs. gRPC

Funkcja|REST|gRPC
|—|—|—
|Protokół HTTP|HTTP 1.1|HTTP 2
|Obsługa przeglądarki|Wspiera wszystkie przeglądarki (HTTP/1.1)|Ograniczona (HTTP/2)
|Generowanie kodu|Narzędzia zewnętrzne|Wbudowane funkcje
|Podejście projektowe|Zorientowane na jednostki|Zorientowane na usługi
|Dostęp do danych|Adresy URL zasobów|Wywołania usług
|Dwukierunkowe strumieniowanie danych|Niedostępne|Dostępne
|Wdrożenie|Brak specjalnego oprogramowania|Wymaga oprogramowania gRPC (klient i serwer)
|Model komunikacji|Jeden klient – jeden serwer|Wiele modeli (np. 1 klient-wiele serwerów, 1 serwer – wielu klientów, 1 serwer – 1 klient)

Kiedy używać REST

API RESTful oraz usługi sieciowe są bardzo popularne z uwagi na łatwość wdrażania, czytelność danych i elastyczność. REST sprawdzi się w sytuacjach:

• Architektury webowe: do tworzenia API webowych, mobilnych i wieloplatformowych.
• Prosta komunikacja danych: REST korzysta z JSON, formatu łatwego do odczytania.
• Publiczne API: REST jest dobrym wyborem dla publicznie dostępnych API ze względu na czytelność.

Kiedy używać gRPC

gRPC nie jest tak popularne jak REST, ale oferuje unikalne cechy przydatne w następujących przypadkach:

• Systemy wielojęzyczne: gRPC nadaje się do mikroserwisów pisanych w różnych językach, gdzie struktura API nie ulega częstym zmianom.
• Komunikacja mikroserwisów: funkcje takie jak dwukierunkowe przesyłanie i ograniczone wsparcie dla przeglądarek sprawiają, że gRPC dobrze sprawdza się w wewnętrznych API.
• Przesyłanie strumieniowe w czasie rzeczywistym: gRPC może być użyte w systemach obsługujących duże ilości danych i przesyłanie strumieniowe w czasie rzeczywistym.

Opinia autorów

Chociaż gRPC ma cechy, które mogą przewyższać REST w aplikacjach takich jak Internet Rzeczy, REST pozostaje popularniejszym wyborem ze względu na czytelność, elastyczność i uniwersalne zastosowanie. Ograniczone wsparcie przeglądarek przez gRPC nie czyni go dobrym wyborem dla twórców usług internetowych.

Uniwersalna obsługa usług RESTful sprawia, że jest to idealna architektura API do integracji sieci i mikroserwisów.

Wniosek

Zarówno REST, jak i gRPC to popularne style architektur API. Wybór między nimi zależy od specyfiki tworzonego produktu. REST jest idealny do tworzenia publicznych API, a gRPC może być dobrym wyborem dla aplikacji mobilnych, które nie potrzebują wsparcia przeglądarkowego.

Zachęcamy do zapoznania się z naszym artykułem na temat tworzenia gRPC od podstaw z użyciem języka Java.