Być może słyszałeś słowa takie jak REST rzucone wokół, gdy chodzi o rozwój oprogramowania. REST jest bardzo powszechnie używaną architekturą API, a programiści powszechnie używają jej do projektowania interfejsów API oprogramowania. Interfejsy programowania aplikacji są niezbędne dla każdej aplikacji, a REST jest jedną z wielu architektur, które są używane dla API.
Obecnie, gRPC architektura zyskuje popularność, a także twierdzi, że rozwiązuje niektóre problemy tradycyjnie związane z interfejsami APIREST . Ale gdzie one się różnią? I który z nich powinieneś wykorzystać w swojej aplikacji? Aby poznać odpowiedź na te pytania, musimy zrozumieć więcej o gRPC vs REST i w jakich scenariuszach sprawdzają się lepiej. Ale zanim wejdziemy w to wszystko, spójrzmy na to, czym są API i co wnoszą do stołu dla mikroserwisów.
Co to jest API?
Aplikacje programowe mogą wchodzić w interakcje i komunikować się ze sobą za pomocą interfejsów programowania aplikacji - API, które działają jako techniczni mediatorzy. API jest odpowiedzialny za wysyłanie żądania użytkownika do systemu, który następnie otrzymuje odpowiedź od systemu.
Wyobraź sobie, że zamawiasz telefon online. Wchodzisz na stronę, która jest połączona z siecią, a ona wysyła informacje o Twoim zapytaniu do serwera. Serwer następnie otrzymuje informacje, analizuje je i po podjęciu niezbędnych kroków odpowiada nam ze szczegółami wyświetlanymi na naszym ekranie. Staje się to możliwe dzięki interfejsom API.
API nakreśla, w jaki sposób wykonywać takie żądania klienta, jakie struktury danych używać i standardy, których klienci muszą przestrzegać. Opisuje również rodzaje zapytań, które jeden program może wysłać do drugiego. Zarówno gRPC vs REST style architektury są szeroko stosowane do projektowania interfejsów API.
Interfejsy API i mikrousługi
Aplikacje mogą mieć albo architekturę monolityczną, albo architekturę mikroserwisową. W aplikacji monolitycznej wszystkie funkcje i moduły oprogramowania zawarte są w jednej jednostce lub bazie kodu. Natomiast aplikacja mikroserwisowa składa się z wielu mniejszych jednostek, które współdziałają ze sobą za pośrednictwem interfejsów, takich jak protokół HTTP.
Głównym problemem stylu monolitycznego jest to, że coraz trudniej jest zmieniać, aktualizować i rozszerzać system, ponieważ inżynierowie dołączają nowe funkcje i usługi do istniejącego wcześniej fundamentu. Zmiana jednego aspektu aplikacji może mieć szkodliwy wpływ na inne sekcje. Kod monolitu stopniowo staje się tak spleciony i trudny do ogarnięcia po tym, jak jest skalowany, aktualizowany i zmieniany wiele razy, że wymagana jest całkowita przebudowa systemu.
Ten problem jest rozwiązywany za pomocą mikroserwisów. Ten projekt architektoniczny dzieli monolit na jego elementy składowe, z których każdy jest następnie uruchamiany jako osobna aplikacja. Każda z tych aplikacji jest nazywana mikroserwisem. Następnie, te odrębne mikroserwisy łączą się za pomocą interfejsów API. Ta kolekcja mikroserwisów połączonych za pomocą interfejsów API łączy się, aby zbudować większy projekt architektury. Interfejsy API umożliwiają połączenie i komunikację między każdym komponentem włączonym do architektury mikroserwisu. Niektóre popularne podejścia do tworzenia interfejsów API to GraphQL, RPC, oraz REST.
Czym jest. RPC?
An RPC - Remote Procedure Call - to architektura internetowa, która umożliwia wykonanie usługi na zdalnym serwerze za pomocą predefiniowanego formularza i uzyskanie odpowiedzi o tym samym formacie. Styl serwera wykonującego zapytanie, czy jest to serwer lokalny czy zdalny, nie jest brany pod uwagę przez RPC projekt.
Image Source itrelease.com/Autor Junaid Rehman
Podstawowa funkcja RPC API request jest taka sama jak w przypadku API REST. Żądania RPC Żądania API określają wytyczne dotyczące interakcji i techniki, które umożliwiają interakcję. Później użytkownik wywołuje te funkcje za pomocą parametrów. Ciąg żądania w adresach URL zawiera parametry używane do wywoływania operacji.
Aby utworzyć żądania API, system RPC system wykorzystuje strukturę klient-serwer. RPC Interpretuje informacje, których żąda użytkownik i przekazuje je do serwera. Podczas gdy wewnętrzna komunikacja wewnątrz serwerów jest ukryta, serwer odpowiada użytkownikowi. Model RPC Model ten umożliwia również użytkownikowi zapytanie o usługę w określony sposób. RPC ma tę zaletę, że obsługuje zdalne wywołania procedur zarówno w scenariuszach zdecentralizowanych, jak i stacjonarnych.
Co to jest REST?
REST - Representational State Transfer - odnosi się do architektury klient-serwer, w której użytkownicy mają dostęp do informacji backendowych za pośrednictwem komunikacji JSON lub XML. API jest uważane za RESTful, jeśli:
- Posiada spójny interfejs i udostępnia klientom API poszczególne zasoby aplikacji.
- Serwer i klient pracują oddzielnie i niezależnie. Klientowi znane są tylko URI wskazujące na komponenty aplikacji.
- Jest to rozwiązanie bezstanowe. Oznacza to, że tylko klient zapisuje jakiekolwiek informacje o stanie. Serwer nie zapisze żadnych danych stanowych o zapytaniu klienta.
- Zasoby aplikacji, które są dostarczane przez API muszą być buforowalne.
- Posiada architekturę warstwową.
Jest to zastosowanie współczesnych projektów architektonicznych, które zależą od kilku ograniczeń, aby umożliwić przesyłanie danych w sieciach hipermedialnych. RESTful web API potrzebuje argumentów zakodowanych w adresie URL, aby połączyć się z usługami za pomocą protokołów HTTP. REST Interfejsy API zostały szeroko przyjęte we współczesnych projektach internetowych, aby stworzyć bezstanowe, rozszerzalne i niezawodne interfejsy API.
Każdy komponent, który łączy system mikroserwisów, może być wyświetlony użytkownikowi lub klientowi jako zasób, gdy interfejs API REST jest publicznie dostępny. Zasób ten można odpytywać za pomocą poleceń HTTP GET, POST, PUT i DELETE .
Jak działa REST?
REST używa protokołu HTTP jako domyślnego protokołu komunikacyjnego podczas pracy z usługami, które są określone w żądaniach API. Zasób to rzecz, która jest porównywalna do obiektu w projektowaniu obiektowym. Zasób RESTful ma działania i atrybuty, podobnie jak obiekt. Ogólnie rzecz biorąc, implementacje REST zazwyczaj dają mniej myśli o działaniach RESTful i zamiast tego koncentrują się bardziej na atrybutach zasobu. Rozwiązania RESTful to te, które po prostu używają atrybutów do reprezentowania zasobu RESTful.
W RESTful API użytkownik składa zapytanie do adresu URL - Uniform Resource Locator, co powoduje odpowiedź z ładunkiem w JSON, XML lub dowolnym obsługiwanym formacie danych. Ten ładunek reprezentuje zasób, którego chce użytkownik. Typowe żądania klienta obejmują
- Metodę HTTP, która określa, co ma być przetworzone na zasobie
- Ścieżkę dostępu do zasobu
- Nagłówek, który zawiera dane o zapytaniu
- Ładunek wiadomości specyficzny dla klienta
W polu Accept nagłówka użytkownik określa typy danych, które jest w stanie odebrać. Nagłówek content-type, który identyfikuje format dostarczenia wiadomości zastosowany w treści odpowiedzi, jest wysyłany przez serwer API wraz z ładunkiem danych, który dostarcza użytkownikowi składającemu zapytanie. Kod odpowiedzi, który informuje użytkownika o statusie wyniku wywołania API, jest również zawarty w ciele odpowiedzi.
Czym jest. gRPC?
gRPC - Google Remote Procedure Call - jest podtypem projektu RPC. gRPC jest wysokowydajną globalną, otwartą architekturą RPC, która gwarantuje elastyczność i szybkość dla architektury mikroserwisów. Wywołania funkcji są używane przez gRPC do zapewnienia interakcji z klientami w mikroserwisach tworzonych przy użyciu różnych języków kodowania.
Technika ta implementuje RPC żądania API z wykorzystaniem standardu HTTP 2.0, ale ani serwer, ani programista API nie są uświadamiani w zakresie protokołu HTTP. W rezultacie komplikacja jest zmniejszona, ponieważ nie ma powodu, aby martwić się o to, jak zasady RPC są tłumaczone na HTTP.
Google Remote Procedure Call stara się przyspieszyć przesyłanie danych przez mikroserwisy. Aby umożliwić zdalny powrót i wywołanie, opiera się na strategii, która identyfikuje usługę, ustanawia metodologie i określa odpowiednie zmienne.
Dodatkowo używa IDL - języka opisu interfejsu - do określenia paradygmatu RPC API, co upraszcza identyfikację zdalnych funkcji. IDL domyślnie stosuje bufory protokołów do definiowania interfejsu usług i formatu komunikatów payload.
Jak gRPC działa?
Protokół HTTP/2, streaming oraz bufory protokołów lub protobufs są wykorzystywane przez gRPC API do przesyłania wiadomości. Standard serializacji zwany protobuf pozwala na automatyczne tworzenie bibliotek użytkownika i prostą budowę mikroserwisów. W plikach proto projektanci API opisują operacje i komunikaty, które są przesyłane przez serwery i klientów.
Kompilator protoc ładuje pliki i tworzy oprogramowanie użytkownika i serwera do komunikacji ze zdalnymi usługami. W porównaniu z formatami XML lub JSON, wiadomości zaszyfrowane za pomocą buforów protokołów są znacznie mniejsze, dzięki czemu ich przetwarzanie jest mniej CPU-intensywne.
Dodatkowo, wykorzystując HTTP/2, gRPC API wnoszą różne ulepszenia do projektu RPC. Protokół ten dodaje warstwę formatu binarnego, która dzieli pakiety na mniejsze, binarne wiadomości, czyniąc je transportowalnymi i małymi. Wykonywanie wielu połączeń wewnątrz pojedynczego kanału jest możliwe dzięki obsłudze przez HTTP/2 wielu jednoczesnych zapytań z dwukierunkową architekturą komunikacji.
Protokół transportowy HTTP/2 obsługuje wiele współbieżnych strumieni, ale gRPC API rozszerzają tę funkcjonalność poprzez kanały. Każdy kanał może pomieścić kilka strumieni działających jednocześnie przez wiele równoległych połączeń. Kanały oferują prostą metodę łączenia się z serwerem API pod danym adresem i portem. Stub klienta może być również wykonany poprzez kanały.
gRPC vs REST: porównanie
Google stworzyło gRPC jako wariant RPC, aby poradzić sobie z niektórymi ograniczeniami istniejących stylów architektury API. Rozwiązuje on niektóre problemy związane z REST API, ale gRPC API napotykają pewne problemy ze względu na to, że jest to nowsza technologia. Istnieje wiele przypadków użycia, w których interfejsy API REST mogą być lepiej dopasowane do Twojej aplikacji. Możesz zdecydować, który z tych interfejsów API może lepiej działać z twoim oprogramowaniem, gdy znasz różnice między nimi.
HTTP 1.1 vs HTTP 2
Podejście typu żądanie-odpowiedź stosowane przez REST API opiera się przede wszystkim na HTTP 1.1. Oznacza to, że model musi przetwarzać każde zapytanie indywidualnie, jeśli mikroserwis otrzymuje wiele zapytań od wielu klientów, co obciąża cały system. REST API mogą być tworzone na HTTP 2, ale ponieważ architektura komunikacji to nadal żądanie-odpowiedź, nie są w stanie w pełni wykorzystać zalet HTTP 2, w tym dwukierunkowej kompatybilności i interakcji strumieniowej.
gRPC Interfejsy API nie napotykają tego wyzwania. Trzyma się modelu połączenia klient-odpowiedź i jest oparty na HTTP 2. gRPC może przyjmować wiele zapytań od różnych klientów i przetwarzać te żądania w tym samym czasie poprzez strumień informacji. Te okoliczności pozwalają na dwukierunkową komunikację z interakcją strumieniową. Dodatkowo, gRPC obsługuje interakcje jednoargumentowe, jak te stworzone przez HTTP 1.1.
gRPC API mogą zarządzać:
- Interakcje jednoargumentowe
Jeśli klient wykonuje jedno żądanie, ale w zamian otrzymuje tylko jedną odpowiedź. - Strumieniowe przesyłanie danych przez serwer
Jest to znane jako strumieniowanie serwera, gdy serwer odpowiada na zapytanie klienta strumieniem wiadomości. Serwer wysyła również wiadomość o stanie, aby zakończyć procedurę po dostarczeniu wszystkich danych. - Client-streaming
Występuje, gdy klient dostarcza sekwencję wiadomości, a serwer odpowiada pojedynczą wiadomością. - Strumieniowanie dwukierunkowe
Pozwala na przesyłanie danych w obie strony, ponieważ kanały serwera i klienta są od siebie niezależne.
Obsługa przeglądarek.
Ponieważ większość interakcji web API odbywa się online, obsługa przeglądarki jest kluczowym czynnikiem w debacie gRPC vs. REST. Obsługa przeglądarki jest prawdopodobnie jedną z kluczowych zalet interfejsów API REST w porównaniu z gRPC. Wszystkie przeglądarki oferują pełne możliwości REST API i obsługę przeglądarki. Funkcjonalność dla gRPC w przeglądarkach jest jednak nadal stosunkowo ograniczona. Niestety, przejścia pomiędzy HTTP 1.1 i HTTP 2 wymagają gRPC-web, jak również warstwy proxy. W rezultacie, gRPC API są zazwyczaj wykorzystywane głównie w systemach wewnętrznych lub prywatnych, na przykład w aplikacjach API wykorzystywanych do obsługi informacji i funkcjonalności backendu określonych organizacji.
Strumienie multipleksowane są używane z protokołem HTTP/2. W efekcie liczni klienci mogą równolegle wysyłać zapytania bez konieczności otwierania nowej sesji TCP dla każdego z nich. Dodatkowo serwer może wykorzystać istniejące łącze do dostarczenia wiadomości do klientów.
Model reprezentacyjnego transferu stanu ma szerokie wsparcie dla przeglądarek, ponieważ integruje HTTP 1.1. HTTP 1.1, który umożliwia REST, używa metody handshaking TCP dla każdego zapytania. REST W rezultacie interfejsy API często mają problemy z opóźnieniami, ponieważ uścisk dłoni wymaga czasu.
Struktura danych "Payload
Jeśli patrzymy na strukturę danych payload patrząc na gRPC vs REST, gRPC API serializują dane payloadu używając buforów protokołu z założenia. Ta metoda jest lżejsza, ponieważ sprawia, że wiadomości są mniejsze i pozwala na wysoce skompresowaną strukturę. Bufory protokołów są w formacie binarnym; dlatego do wymiany danych serializuje i deserializuje informacje. Protobuf może automatycznie tłumaczyć mocno napisane wiadomości na języki programowania klienta i serwera.
RESTJednak do dostarczania i odbierania informacji najczęściej używa się formatów JSON lub XML. JSON jest najczęściej używanym formatem ze względu na jego możliwości adaptacyjne i zdolność do przekazywania dynamicznych danych bez przestrzegania precyzyjnej struktury, chociaż jej nie wymaga. Jakość JSON w zakresie czytelności dla człowieka, której Protobuf nie może jeszcze dorównać, jest kolejną ważną zaletą.
JSON nie jest jednak tak szybki i lekki, gdy chodzi o przesyłanie danych. Wynika to z wymogu, że JSON powinien być serializowany i tłumaczony na języki programowania stosowane zarówno po stronie serwera, jak i klienta, gdy używa się REST. Jest to dodatkowy krok w procesie przesyłania danych, który może zaszkodzić wydajności i zwiększyć prawdopodobieństwo wystąpienia błędów.
Generowanie kodu
Inżynierowie muszą stosować narzędzia innych firm, takie jak Postman, do generowania kodu dla zapytań API, ponieważ - w przeciwieństwie do gRPC, w API REST brakuje wbudowanych urządzeń do generowania kodu. W przeciwieństwie do tego, gRPC oferuje natywne funkcje generowania kodu dzięki kompilatorowi protoc, który obsługuje wiele języków programowania. Generowanie kodu jest szczególnie korzystne dla mikroserwisów, które łączą wiele usług stworzonych na wielu platformach i językach. Ogólnie rzecz biorąc, jego wbudowane generowanie kodu ułatwia konstruowanie zestawu do tworzenia oprogramowania - SDK.
REST Z drugiej strony, API nie zapewnia natywnych funkcji generowania kodu. Musisz wykorzystać program innej firmy do generowania kodu dla wywołań API w wielu językach. Chociaż nie jest to kłopotliwe, ważne jest, aby zauważyć, że gRPC nie polega na żadnych innych usługach do generowania kodu.
Kiedy używać REST API
Porównując gRPC vs REST, najszerzej stosowanymi i najbardziej lubianymi interfejsami API do integracji infrastruktur zbudowanych na mikroserwisach są interfejsy API REST. REST API prawdopodobnie jeszcze przez bardzo długi czas będą domyślną opcją łączenia aplikacji, niezależnie od tego, czy tworzymy wewnętrzną sieć, czy otwartą platformę, która otwiera swoje zasoby na resztę świata. REST Interfejsy API są również idealne dla systemów wymagających szybkiej iteracji i standardów protokołu HTTP.
REST Interfejsy API mogą być Twoim pierwszym wyborem dla rozwoju usług internetowych, mikroserwisów i interfejsów aplikacji, ponieważ technologie stron trzecich powszechnie je wspierają. W przeciwieństwie do gRPC, ma szerokie wsparcie dla przeglądarki i nie jest ograniczone do prywatnych systemów. To może sprawić, że REST API są bardzo przydatne w wielu kontekstach.
Łatwiej jest również nauczyć się REST, ponieważ ma szeroką dokumentację API dostępną w Internecie. Ta prostsza krzywa uczenia się jest bardzo ważna, jeśli jesteś na skróty. Możesz zaoszczędzić dużo czasu na badania i naukę i zacząć wdrażać natychmiast. RESTful API są również łatwiejsze do zintegrowania z aplikacjami. Oferują one również lepszą skalowalność. Jeśli chcesz wkrótce rozszerzyć swoją aplikację, może lepiej użyć interfejsów API REST. Brak stanu i poufności może powodować problemy z reprezentacyjnym przekazywaniem stanu w niektórych aplikacjach. Jeśli twoja aplikacja ma opcję płatności, gRPC może być lepszą opcją.
Kiedy używać gRPC APIs
W obu gRPC vs REST, większość narzędzi firm trzecich nadal nie zapewnia wbudowanej funkcjonalności dla gRPC zgodności. W rezultacie, gRPC API są najczęściej używane do tworzenia wewnętrznych systemów lub struktur, które są niedostępne dla użytkowników zewnętrznych. Mając na uwadze tę kwalifikację, następujące sytuacje mogą wykorzystywać gRPC API:
- Połączenia w ramach mikroserwisów
gRPC API są szczególnie pomocne w łączeniu architektur złożonych z lekkich mikroserwisów, gdzie efektywność dostarczania komunikatów jest kluczowa ze względu na niskie opóźnienia i szybką komunikację pasmową.
- Systemy wielojęzyczne
gRPC gRPC wyróżnia się w obsłudze komunikacji w kontekście poliglotycznym dzięki możliwości generowania kodu natywnego dla szerokiego zakresu języków programowania.
- Strumieniowanie w czasie rzeczywistym
Jeśli konieczna jest komunikacja w czasie rzeczywistym, Twój system może przesyłać i odbierać dane w czasie rzeczywistym bez konieczności oczekiwania na interakcję klient-odpowiedź Unary dzięki możliwości obsługi dwukierunkowego przesyłania strumieniowego przez gRPC.
- Sieci o małej mocy i małej przepustowości
Takie sieci mogą skorzystać z wykorzystania przez gRPC serializowanych sesji Protobuf, ponieważ zapewniają one lekką komunikację, lepszą wydajność i szybkość. Na przykład, siecią, która mogłaby skorzystać z API jest gRPC API jest Internet Rzeczy.
Jak pomaga AppMaster?
Programowanie bardzo się zmieniło w ostatnich dekadach, a nowe technologie i frameworki ułatwiają zadania programistów. No-code generation przenosi to na wyższy poziom. Ludzie nie muszą przechodzić przez strome krzywe uczenia się i mogą szybciej tworzyć aplikacje dzięki no-code platformy takie jak AppMaster.
AppMaster pomaga stworzyć kod źródłowy od podstaw zgodnie z konkretnymi potrzebami Twojej aplikacji. Wygenerowany kod będzie należał do Ciebie i możesz go modyfikować zgodnie ze swoimi potrzebami. Możesz stworzyć różne moduły, których potrzebuje Twoja aplikacja, korzystając z AppMaster. Jest to znacznie mniej kosztowne i czasochłonne niż angażowanie całego zespołu programistów do zrobienia tego samego.
Programiści mogą wysyłać zapytania pomiędzy backendową architekturą mikroserwisów za pomocą gRPC używając platformy generującej no-code firmy AppMaster. Dodamy API zarówno do gRPC rozwoju usług internetowych, jak również gRPC aplikacji mobilnych w następnym roku, aby zwiększyć gRPC wsparcia.
Podsumowanie
Reprezentacyjny transfer stanu był podejściem go-to, jeśli chodzi o rozwój API w przeszłości. Ale między gRPC vs REST, gRPC API powoli stają się coraz bardziej popularne. Pomimo różnych cech, które sprawiają, że wyróżnia się, niektóre problemy, takie jak brak wsparcia dla przeglądarki i dokumentacji API, utrudniają zatrudnienie go wszędzie. Jednakże, wraz z postępem technologicznym i rozwojem społeczności, możemy mieć nadzieję, że gRPC pokona dzisiejsze wyzwania.
Wreszcie, wybierając między REST lub gRPClub nawet którąkolwiek z innych metodologii API, takich jak GraphQL lub SOAP, zależy od konkretnych potrzeb twojego projektu. Niektóre aplikacje mogą potrzebować korzyści, które gRPC podczas gdy inne mogą wymagać podstawowej funkcjonalności, którą zapewnia REST. Musisz ocenić funkcje i przypadki użycia swojej aplikacji, aby wybrać między tymi dwoma zdolnymi technologiami.
