In che modo GRPC è diverso da REST?

Sto leggendo questa spiegazione di GRPC e questo diagramma è interessante:

Come funziona il livello di trasporto? Se è sulla rete ... perché si chiama RPC? Ancora più importante, in che cosa differisce da REST che implementa un'API per il livello di servizio (la classe nel client che ha metodi che effettuano una richiesta http)?

Il livello di trasporto funziona utilizzando HTTP / 2 su TCP / IP. Consente connessioni a latenza inferiore (più veloci) che possono trarre vantaggio da una singola connessione da client a server (che fa un uso più efficiente della connessione e può comportare un uso più efficiente delle risorse del server.

HTTP / 2 supporta anche la connettività bidirezionale e la connettività asincrona. Quindi è possibile che il server si contatti in modo efficiente con il client per inviare messaggi (risposta / notifiche asincrone, ecc.)

Mentre, sia REST che gRPC possono generare stub client / server (usando qualcosa come swagger per REST), REST ha un set limitato di chiamate (o verbi) di 'funzione' primarie:

+ ----------- + ---------------- +
| Verbo HTTP | CRUD |
+ ----------- + ---------------- +
| OTTIENI | Leggi |
| PUT | Aggiorna / Sostituisci |
| PATCH | Aggiorna / Modifica |
| DELETE | Elimina |
+ ----------- + ---------------- +

considerando che gRPC è possibile definire qualsiasi tipo di chiamata di funzione tra cui sincrono / asincrono, unidirezionale / bidirezionale (flussi), ecc.

Utilizzando gRPC il client effettua una chiamata a un metodo locale. Per il programmatore, sembra che tu stia effettuando una chiamata locale, ma il livello sottostante (lo stub del client generato automaticamente) invia la chiamata al server. Al server sembra che il suo metodo sia stato chiamato localmente.

gRPC si prende cura di tutte le tubature sottostanti e semplifica il paradigma di programmazione. Tuttavia, per alcuni puristi REST dedicati, questa può sembrare una complicazione eccessiva. YMMV

REST non richiede JSON o HTTP / 1.1

Puoi costruire banalmente un servizio RESTful che invia messaggi protobuf (o qualsiasi altra cosa) su HTTP / 2

Puoi creare servizi RESTful che inviano JSON su HTTP / 2

Puoi creare servizi RESTful che inviano messaggi protobuf su HTTP / 1.1

I servizi RESTful non sono un "hack" sopra HTTP / xx, sono servizi che seguono i principi architettonici fondamentali che hanno reso efficace qualsiasi versione di HTTP (come la cachebility delle richieste GET e la rigiocabilità delle richieste PUT).

gRPC, SOAP, et. Tutti sono più simili agli hack: hack su HTTP per eseguire il tunneling di servizi in stile RPC su HTTP, per aggirare le restrizioni di firewall e middlebox. Non è necessariamente una cosa negativa. A volte potresti volere un servizio in stile RPC invece di uno REST, e dobbiamo vivere in un mondo in cui i middlebox sono difficili da sostituire.

Se non hai tempo per leggere la definizione effettiva di REST: https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

C'è sempre il TLDR; versione su wikipedia:

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

Se hai bisogno di un servizio in stile RPC, certo, gRPC è fantastico. Se vuoi vivere sul Web o desideri tutti i vantaggi offerti da un servizio in stile RESTful, crea un servizio in stile RESTful. E se è troppo lento serializzare / deserializzare i dati in formato JSON nel tuo servizio riposante, è perfettamente OK usare protobuf o qualsiasi altra cosa.

Se gRPC è una versione 2 di qualcosa, è una versione 2 di SOAP. Uno che non è terribile, come SOAP.

E no, non puoi semplicemente "chiamare qualsiasi funzione" nella tua richiesta GET e avere un servizio RESTful.

Un'ultima cosa: se intendi utilizzare protobuf su un servizio RESTful, fallo bene, usando le intestazioni del tipo di contenuto, ecc. Con ciò, puoi facilmente supportare sia JSON CHE protobuf.

Ora sto scendendo dalla mia scatola SOAP ..;)

Il più grande vantaggio di gRPC su REST è il suo supporto di HTTP / 2 su nonno HTTP 1.1. Quindi il più grande vantaggio di HTTP / 2 su HTTP 1.1 è che "HTTP / 2 consente al server di" spingere "il contenuto" ...