Czym różni się GRPC od REST?


98

Czytam to wyjaśnienie GRPC i ten diagram jest interesujący:

wprowadź opis obrazu tutaj

Jak działa warstwa transportowa? Jeśli jest przez sieć ... dlaczego nazywa się to RPC? Co ważniejsze, czym różni się to od REST, który implementuje API dla warstwy usług (klasa w kliencie, która ma metody, które wykonują żądanie http)?


20
„Jeśli jest przez sieć… dlaczego nazywa się to RPC” - Ponieważ RPC to zdalne wywołanie procedury, a „zdalne” może oznaczać „na innym hoście”.
dziwaczny

Odpowiedzi:


104

Warstwa transportowa działa przy użyciu protokołu HTTP / 2 nad protokołem TCP / IP. Pozwala na mniejsze opóźnienia (szybsze) połączenia, które mogą korzystać z pojedynczego połączenia od klienta do serwera (co efektywniej wykorzystuje połączenie i może skutkować bardziej efektywnym wykorzystaniem zasobów serwera.

Protokół HTTP / 2 obsługuje również łączność dwukierunkową i łączność asynchroniczną. Dzięki temu serwer może efektywnie kontaktować się z klientem w celu wysyłania wiadomości (asynchroniczna odpowiedź / powiadomienia itp.)

Podczas gdy zarówno REST, jak i gRPC mogą generować kody pośredniczące klienta / serwera (używając czegoś takiego jak Swagger dla REST), REST ma ograniczony zestaw podstawowych wywołań funkcji (lub czasowników):

+ ----------- + ---------------- +
| Czasownik HTTP | CRUD |
+ ----------- + ---------------- +
| GET | Przeczytaj |
| PUT | Aktualizuj / zamień |
| PATCH | Aktualizuj / modyfikuj |
| USUŃ | Usuń |
+ ----------- + ---------------- +

podczas gdy gRPC można zdefiniować dowolny rodzaj wywołań funkcji, w tym synchroniczne / asynchroniczne, jednokierunkowe / dwukierunkowe (strumienie) itp.

Korzystając z gRPC, klient wywołuje metodę lokalną. Dla programisty wygląda na to, że wykonujesz wywołanie lokalne, ale warstwa bazowa (automatycznie wygenerowany kod klienta) wysyła to wywołanie do serwera. Dla serwera wygląda na to, że jego metoda została wywołana lokalnie.

gRPC zajmuje się całą podstawową instalacją wodno-kanalizacyjną i upraszcza paradygmat programowania. Jednak niektórym oddanym purystom REST może się to wydawać nadmierną komplikacją. YMMV


2
A więc krótkie pytanie: w REST możesz też wywołać jakąkolwiek funkcję. Na przykład w Railsach mogę wysłać żądanie GET do punktu końcowego, który nie jest zgodny z REST i zrobić coś więcej niż tylko uzyskanie zasobu. Mogę wykopać naprawdę każdą funkcję z tego punktu końcowego nie obsługującego REST. Mogę również tworzyć usługi w REST, które wydają się wywoływać metodę lokalną, ale naprawdę pod maską wykonują wywołanie http do punktu końcowego. Więc różnice nie są tak duże, że są ... przynajmniej w warstwie transportowej. Albo czy oni?
Jwan622

2
REST / RESTful działa przez HTTP, gRPC działa przez HTTP / 2 (jak WebSocket). Korzystając z generatora kodu firmy Swagger, można generować kody pośredniczące klienta i serwera dla REST, gRPC używa pliku proto do generowania jego kodów pośredniczących (podobnie jak w starym podejściu WSDL / SOAP). Plik proto definiuje typ, więc wygenerowane kody pośredniczące klienta / serwera są bezpieczne. Na urządzeniu przenośnym połączenie gRPC jest wydajne, ponieważ może współużytkować to samo podstawowe gniazdo HTTP / 2 z innymi równoczesnymi połączeniami z aplikacji mobilnej.
mmccabe


1
Jwan622 i mmccabe: Korzystając z biblioteki Superglue 2.1, mogę zbudować dom z jabłkami i pomarańczami. W pewnym momencie musimy wybrać odpowiednie narzędzie do pracy i zawsze starać się zminimalizować złożoność naszego systemu oprogramowania. Pamiętaj, usuwanie kodu jest zawsze optymalizacją wydajności;)
Martin Andersson

4
Z mojego punktu widzenia rzeczy takie jak RESTful API zawsze były „hackem”, do którego należało używać starych protokołów. Jeśli pojawi się coś, co pozwoli mi użyć stosu bardziej odpowiedniego dla współczesnych języków i nadal być agnostykiem w odniesieniu do konkretnego języka używanego przez klienta ORAZ dramatycznie zwiększyć wydajność, to będę pierwszą osobą, która wskoczy na modę!
Martin Andersson,

42

REST nie wymaga formatu JSON ani HTTP / 1.1

Możesz w trywialny sposób zbudować usługę RESTful, która wysyła wiadomości protobuf (lub cokolwiek innego) przez HTTP / 2

Możesz tworzyć usługi RESTful, które wysyłają JSON przez HTTP / 2

Możesz budować usługi RESTful, które wysyłają komunikaty protobuf przez HTTP / 1.1

Usługi RESTful nie są „hackem” w stosunku do HTTP / xx, są to usługi działające zgodnie z podstawowymi zasadami architektury, które sprawiły, że każda wersja HTTP zakończyła się sukcesem (np. Możliwość buforowania żądań GET i odtwarzalność żądań PUT).

gRPC, SOAP, et. wszystkie są bardziej jak hacki - hacki na szczycie HTTP do tunelowania usług w stylu RPC przez HTTP, do omijania ograniczeń zapory i skrzynki pośredniej. To niekoniecznie jest złe. Czasami możesz chcieć usługi w stylu RPC zamiast REST, a my musimy żyć w świecie, w którym ciężko jest wymienić middleboxy.

Jeśli nie masz czasu na zapoznanie się z rzeczywistą definicją REST: https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

Zawsze istnieje TLDR; wersja na wikipedii:

https://en.wikipedia.org/wiki/Representational_state_transfer

Jeśli potrzebujesz usługi w stylu RPC, z pewnością gRPC jest świetny. Jeśli chcesz żyć w sieci lub chcesz czerpać korzyści z usługi w stylu RESTful, utwórz usługę w stylu RESTful. A jeśli serializacja / deserializacja danych w formacie JSON w Twojej spokojnej usłudze jest zbyt powolna, możesz użyć protobuf lub cokolwiek innego.

Jeśli gRPC jest wersją 2 czegokolwiek, jest to wersja 2 protokołu SOAP. Taki, który nie jest straszny, jak SOAP.

I nie, nie możesz po prostu „wywołać dowolnej funkcji” w żądaniu GET i mieć usługę RESTful.

I ostatnia rzecz: jeśli zamierzasz używać protobufów zamiast usługi RESTful, zrób to dobrze, używając nagłówków typów zawartości itp. Dzięki temu możesz łatwo obsługiwać zarówno JSON, jak i protobuf.

Wychodzę teraz z mojej skrzynki SOAP ..;)


Czy sugerujesz, że nie można utworzyć usługi RESTful przy użyciu gRPC?
Kevin S,

1
RTFM cytując rozprawę Fieldinga było przesadą, ale poza tym świetną reakcją.
rmharrison

4

Największą zaletą gRPC over REST jest obsługa protokołu HTTP / 2 w porównaniu z protokołem dziadka HTTP 1.1. Zatem największą zaletą protokołu HTTP / 2 nad HTTP 1.1 jest to, że „HTTP / 2 umożliwia serwerowi„ wypychanie ”zawartości” ...


1
Serwer push nie wymaga protokołu HTTP / 2.
Robin Green

Możesz być bardziej dokładny? Oto wiki mówiące o wypychaniu serwera HTTP / 2: en.wikipedia.org/wiki/HTTP/2_Server_Push
Denis Wang,

2
Przepraszam, nie miałem na myśli push serwera HTTP 2, miałem na myśli odpowiedzi strumieniowe. Istnieją inne sposoby przesyłania strumieniowego odpowiedzi, na przykład czcigodny długi odpytywanie lub gniazda sieciowe.
Robin Green

1
Serwer gRPC nie wysyła „push” protokołu HTTP / 2, a klient gRPC ignoruje „push” protokołu HTTP / 2. Dlatego zalety gRPC odziedziczone po protokole HTTP / 2 nie powinny obejmować funkcji „push”.
user675693
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.