Czytam to wyjaśnienie GRPC i ten diagram jest interesujący:
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)?
Odpowiedzi:
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
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 ..;)
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” ...