Podczas pracy z interfejsami API często napotkasz REST i gRPC. Mimo że Rest dominuje w tej dziedzinie od wielu lat, gRPC okazuje się godnym konkurentem.
Reszta i gPRC to dwa różne sposoby projektowania interfejsu API. Interfejsy API działają jak most komunikacyjny między usługami, które mogą reprezentować złożone systemy rezydujące na różnych komputerach lub napisane w różnych językach.
W tym artykule przedstawiono zarówno Rest, jak i gRPC, udostępniono ich podobieństwa i różnice oraz miejsca ich użycia.
Spis treści:
Czym jest odpoczynek?
Odpoczynek (Representational State Transfer) to architektoniczne podejście do oprogramowania, które dyktuje zasady dotyczące wymiany danych przez komponenty oprogramowania. Reszta jest oparta na standardowym protokole komunikacyjnym sieci, HTTP.
Wszystkie interfejsy API oparte na architekturze REST nazywane są interfejsami API RESTful. Z drugiej strony usługi internetowe zgodne z projektem architektonicznym REST są znane jako usługi sieciowe RESTful.
Styl architektoniczny REST kieruje się tymi zasadami;
- Jednolity interfejs: Serwer powinien przesyłać dane w standardowym formacie. Jednak przesyłane dane mogą być w innym formacie niż wewnętrzna reprezentacja zasobu aplikacji serwera.
- Bezpaństwowość: serwer powinien realizować każde żądanie klienta niezależnie, niezależnie od poprzednich żądań. Żądania klientów dotyczące zasobów mogą być w dowolnej kolejności, a każde żądanie jest odizolowane od pozostałych.
- System warstwowy: Przedstawia warstwę autoryzowanych pośredników między serwerem a klientem. Klient może łączyć się z tymi autoryzowanymi pośrednikami i nadal otrzymywać odpowiedzi z serwera.
- Pamięć podręczna: niektóre odpowiedzi są przechowywane u pośrednika lub klienta w celu skrócenia czasu odpowiedzi.
- Kod na żądanie: serwery tymczasowo dostosowują lub rozszerzają funkcjonalność klienta, przesyłając klientowi kod oprogramowania.
Korzyści z RESTu
- Skalowalność: interfejsy API REST są znane ze swojej skalowalności, ponieważ optymalizują interakcje klient-serwer. Buforowanie i bezstanowość to główne funkcje zmniejszające obciążenie serwera.
- Elastyczność: interfejsy API RESTful oferują całkowitą separację klient-serwer. Takie usługi oddzielą i uprością różne komponenty serwera, które mogą ewoluować niezależnie.
- Niezależność: aplikacje serwerowe i klienckie można pisać w różnych językach programowania bez wpływu na projekt interfejsu API.
Przypadki użycia Rest
- Interfejsy API sieci Web
- usługi internetowe
- Architektura mikroserwisów
Co to jest gRPC?
gRPC to platforma zdalnego wywoływania procedur (RPC), która może działać w dowolnym środowisku. Ta platforma typu open source została zaprojektowana jako protokół o wysokiej wydajności, który może skutecznie łączyć usługi w centrach danych iw centrach danych.
Aplikacja kliencka może wywoływać metodę w aplikacji serwera na innej maszynie, tak jakby była obiektem lokalnym. Za pomocą gRPC definiujesz usługę i określasz metody, które możesz wywoływać zdalnie wraz z ich parametrami i zwracanymi typami.
gRPC ma podłączaną kontrolę kondycji, uwierzytelnianie, równoważenie obciążenia i obsługę śledzenia. Ta struktura wykorzystuje HTTP 2 i bufory protokołów do transmisji danych. Podczas wymiany danych zamiast adresu URL zasobu wywoływana jest procedura
Korzyści z gRPC
- Skalowalność: gRPC umożliwia instalowanie środowisk wykonawczych za pomocą jednego polecenia i rozpoczęcie skalowania milionów wywołań RPC na sekundę.
- Prosta definicja usługi: Użyj buforów protokołów, aby zdefiniować swoje usługi i uruchomić je.
- Wieloplatformowość: ten framework generuje idiomatyczne kody pośredniczące klienta i serwera dla różnych platform i języków.
- Dwukierunkowe przesyłanie strumieniowe i zintegrowana autoryzacja.
Przypadki użycia gRPC
- Interfejsy API sieci Web
- usługi internetowe
- Aplikacje strumieniowe
- Komunikacja mikroserwisów
Podobieństwa między usługami REST i gRPC
- Mechanizm wymiany danych: Oba projekty architektoniczne umożliwiają serwerom i klientom wymianę danych. Dane te są jednak udostępniane na określonych zasadach.
- Nadaje się do skalowalnych i rozproszonych systemów: asynchroniczna komunikacja i bezstanowa konstrukcja zarówno REST, jak i gRPC ułatwiają skalowanie ich interfejsów API.
- Użyj komunikacji opartej na protokole HTTP: Oba używają protokołu HTTP, najbardziej preferowanego protokołu komunikacyjnego w sieci.
- Elastyczność: REST i gRPC można używać z różnymi językami programowania i technologiami.
REST vs. gRPC: głębokie porównanie nurkowania
Usługi REST i gRPC różnią się w następujący sposób;
Wymiana danych
W REST API dane przekazywane z jednego komponentu oprogramowania do drugiego muszą być wyrażone w formacie JSON. JSON musi zostać zserializowany i przetłumaczony na język programowania w celu wymiany danych. Jednak pozostałe interfejsy API mogą również wymieniać formaty danych, takie jak HTML i XML.
gRPC domyślnie wykorzystuje format buforów protokołów. Jednak natywnie obsługuje JSON. Bufory protokołów nie są czytelne dla człowieka. Serwer używa języka opisu interfejsu Protocol Buffer do zdefiniowania struktury danych. gPRC następnie serializuje strukturę danych do formatu binarnego. Następnie dokona deserializacji danych na dowolne określone języki programowania.
Model komunikacji
W REST klient wysyła pojedyncze żądanie do serwera; serwer następnie wysyła odpowiedź w odpowiedzi. Klient musi czekać na odpowiedź serwera przed kontynuowaniem operacji. Jest to model żądanie-odpowiedź.
W gRPC klient może wysyłać jedno lub wiele żądań serwera, co skutkuje odpowiednio jedną lub wieloma odpowiedziami. Połączenia danych mogą być typu wiele-do-wielu, wiele-do-jednego, jeden-do-wielu lub jeden-do-jednego. gRPC używa modelu komunikacji klient-odpowiedź.
Generowanie kodu
gRPC ma wbudowane natywne funkcje generowania kodu po stronie serwera i klienta. Możesz znaleźć te funkcje w różnych językach dzięki uprzejmości kompilatora Protocol Buffers. gRPC generuje kod po stronie serwera i klienta po zdefiniowaniu struktury w pliku proto.
REST nie ma wbudowanych funkcji generowania kodu. Jeśli potrzebujesz tej funkcji, możesz użyć narzędzi innych firm.
protokół HTTP
Interfejsy API REST używają protokołu HTTP 1.1. Aby wysłać żądanie do usługi REST, potrzebujesz adresu URL zasobu. HTTP 1 przesyła informacje między komputerem a serwerem WWW. Adres URL zasobu w usłudze REST jest widoczny dla klienta. Projektanci API kontrolują strukturę adresów URL zasobów.
gRPC używa HTTP 2. Ta wersja HTTP została wprowadzona w 2015 roku i jest używana w przeglądarkach takich jak Internet Explorer, Safari i Chrome. W przeciwieństwie do HTTP 1, który przechowuje wszystko w postaci zwykłego tekstu, ten nowszy format wykorzystuje enkapsulację formatu binarnego, co daje więcej opcji dostarczania danych i przyspiesza cały proces.
Struktura danych ładunku
REST używa XML lub JSON do wysyłania i odbierania danych. JSON jest najczęściej używanym formatem do przesyłania dynamicznych danych w REST, ponieważ jest elastyczny i nie wymaga żadnej struktury. Dane JSON są również czytelne dla człowieka. Jedyny problem z JSON nie jest tak szybki, ponieważ musi być serializowany i tłumaczony podczas przesyłania danych.
gRPC używa buforów protokołów do serializacji danych ładunku. Jest to wysoce skompresowany format, który ogranicza dane wiadomości. Ta struktura używa Protobuf do automatycznej konwersji wiadomości o silnie wpisanym typie na języki programowania klienta i serwera.
Obsługa przeglądarki
REST jest obsługiwany we wszystkich przeglądarkach, ponieważ używa protokołu HTTP 1.1. To czyni go idealnym wyborem dla usług internetowych i interfejsów API.
Usługa gRPC ma ograniczoną obsługę przeglądarek, ponieważ jest oparta na protokole HTTP 2. Aby obsługiwać wszystkie przeglądarki, należy dodać gRPC-web jako warstwę serwera proxy. Z tego powodu gRPC jest najczęściej stosowany w systemach wewnętrznych.
Sprzężenie klient-serwer
REST to luźno powiązany projekt architektoniczny. Oznacza to, że klient i serwer nie muszą wiedzieć o swoich implementacjach. Ta funkcja ułatwia ewolucję RESTful API w miarę upływu czasu, ponieważ nie trzeba zmieniać kodu klienta podczas modyfikowania definicji serwera.
gRPC to ściśle powiązana struktura, w której serwer i klient muszą mieć dostęp do tego samego pliku proto. Jeśli musisz wprowadzić jakiekolwiek zmiany w pliku, musisz także zaktualizować serwer i klienta.
Odpoczynek a gRPC
FunkcjaRESTgRPCHTTP protokółHTTP 1.1HTTP 2Obsługa przeglądarki Obsługuje wszystkie przeglądarki, ponieważ używa HTTP 1.1 Mniejsza obsługa przeglądarek, ponieważ używa HTTP 2Generowanie koduWykorzystuje narzędzia innych firmWbudowane funkcje generowania koduPodejście projektoweProjektowanie zorientowane na jednostkiPodejście zorientowane na usługiDostęp do danychAdresy URL zasobówWywołania usługDwukierunkowe strumieniowanie danychNiedostępneDostępneWdrożenie Żadne wspólne oprogramowanie nie jest wymagane do wdrożenia REST po stronie klienta lub serwera Oprogramowanie gRPC jest potrzebne zarówno po stronie klienta, jak i serwera. Model komunikacjiPojedynczy klient komunikuje się z jednym serweremWiele modeli komunikacji, na przykład jeden klient wysyła żądania do wielu serwerów, jeden serwer komunikuje się z wieloma klientami lub jeden serwer komunikuje się z jednym klientem.
Kiedy używać REST
RESTful API i usługi sieciowe są bardzo popularne. Usługi RESTful są łatwe do wdrożenia, strukturyzują dane, są elastyczne i czytelne. Możesz użyć REST w następujących przypadkach;
- Architektury oparte na sieci Web: możesz tworzyć sieciowe, mobilne i wieloplatformowe interfejsy API przy użyciu architektury REST.
- Prosta komunikacja danych: REST używa JSON, łatwego do odczytania formatu danych.
- Publiczne interfejsy API: jeśli zamierzasz publicznie konsumować dane i używać twojego interfejsu API, REST będzie dobrym wyborem ze względu na jego funkcję czytelności.
Kiedy używać gRPC
gRPC nie jest tak popularne jak usługi RESTful. Ma jednak również unikalne cechy, które wyróżnią go w następujących aplikacjach;
- Systemy wielojęzyczne: gRPC pasuje do architektur mikrousług napisanych w różnych językach programowania i tam, gdzie interfejs API raczej się nie zmieni.
- Połączenia mikrousług: funkcje, takie jak dwukierunkowe przesyłanie strumieniowe i niska obsługa przeglądarek sprawiają, że gRPC jest dobrym wyborem dla wewnętrznych interfejsów API.
- Sieci przesyłania strumieniowego w czasie rzeczywistym: gRPC można używać z usługami wewnętrznymi, które obsługują duże obciążenia danych i wymagają przesyłania strumieniowego w czasie rzeczywistym.
Opinia autorów
Chociaż gRPC ma pewne specyficzne funkcje, które mogą przyćmić REST w aplikacjach takich jak Internet rzeczy, ten drugi wygrywa ze względu na swoją czytelność, elastyczność i szerokie zastosowanie. Niższa obsługa przeglądarek przez gRPC sprawia, że nie jest to dobry wybór dla programistów, którzy chcą tworzyć usługi sieciowe.
Uniwersalna obsługa usług RESTful sprawia, że REST jest idealną architekturą API do integracji sieci i mikrousług.
Wniosek
REST i gRPC należą do wielu stylów architektury API, które możesz wybrać podczas tworzenia kolejnego API. Ostateczny wybór będzie zależał od produktu, który chcesz zbudować. Usługi RESTful doskonale sprawdzą się podczas tworzenia publicznych interfejsów API, a gRPC to dobry wybór w przypadku usług, takich jak aplikacje mobilne, które nie wymagają obsługi przeglądarki.
Następnie zapoznaj się z naszym artykułem na temat tworzenia gRPC od podstaw przy użyciu języka Java.