Qual è la differenza tra gRPC e REST?
gRPC e REST sono due modi per progettare un'API. Un'API è un meccanismo che consente a due componenti software di comunicare tra loro usando una serie di definizioni e protocolli. In gRPC, un componente (il client) chiama o invoca funzioni specifiche in un altro componente software (il server). In REST, invece di chiamare le funzioni, il client richiede o aggiorna i dati sul server.
Cos'è gRPC?
Cos'è RPC?
In RPC, le comunicazioni client-server funzionano come se le richieste dell'API client fossero un'operazione locale o la richiesta fosse un codice interno del server.
In RPC, un client invia una richiesta a un processo sul server che è sempre in ascolto delle chiamate remote. Nella richiesta, vi è la funzione del server da chiamare, insieme a tutti i parametri da inviare. Un'API RPC utilizza un protocollo come HTTP, TCP o UDP come meccanismo di scambio di dati sottostante.
In che modo gRPC è diverso da RPC?
gRPC è un sistema che implementa l'RPC tradizionale con diverse ottimizzazioni. Ad esempio, gRPC utilizza Protocol Buffers e HTTP 2 per la trasmissione dei dati.
Inoltre, astrae il meccanismo di scambio dei dati dallo sviluppatore. Ad esempio, un'altra implementazione dell'API RPC ampiamente utilizzata, OpenAPI, richiede agli sviluppatori di mappare i concetti RPC al protocollo HTTP. Ma gRPC astrae la comunicazione HTTP sottostante. Queste ottimizzazioni rendono gRPC più veloce, facile da implementare e più ottimizzato per il Web rispetto ad altre implementazioni RPC.
Cos'è REST?
REST è un approccio di architettura software che definisce un insieme di regole per lo scambio di dati tra componenti software. È basato su HTTP, il protocollo di comunicazione standard del Web. Le API RESTful gestiscono le comunicazioni tra un client e un server tramite verbi HTTP, come POST, GET, PUT e DELETE per le operazioni di creazione, lettura, aggiornamento ed eliminazione. La risorsa sul lato server è identificata da un URL noto come endpoint.
REST funziona come segue:
- Il client effettua una richiesta per creare, modificare o eliminare una risorsa sul server
- La richiesta contiene l'endpoint della risorsa e può includere anche parametri aggiuntivi
- Il server risponde restituendo l'intera risorsa al client una volta completata l'operazione
- La risposta contiene dati in formato JSON e codici di stato
Le API create utilizzando le linee guida REST sono chiamate API RESTful o REST API.
Perché le organizzazioni utilizzano gRPC e REST?
gRPC e REST sono due approcci diversi allo sviluppo delle API.
Un'API funziona in modo simile a quando si ordina cibo da un ristorante tramite un menu. In qualsiasi ristorante, un client (cliente) può ordinare cibo dal menu (API), che ha una serie di piatti fissi. Questo viene comunicato alla cucina (server) che prepara il piatto richiesto e lo manda al cliente. Il cliente non deve sapere in che modo la cucina effettua l'ordine, ma solo cosa aspettarsi in cambio della richiesta. La standardizzazione dei formati dei menu significa che clienti e cucine sanno come utilizzarli.
Senza le API, non ci sarebbe un accordo condiviso su come le diverse applicazioni o i servizi software comunicano. I programmatori di due applicazioni separate dovrebbero parlare tra loro per determinare ogni volta come sviluppare lo scambio di dati.
Esistono diversi tipi di architetture API come gRPC e REST perché ogni tipo può essere più adatto a diversi casi d'uso all'interno di un'organizzazione. Un progettista di API deve scegliere l'architettura client-server preferita in base ai requisiti di sistema.
Quali sono le similitudini tra gRPC e REST?
REST e gRPC condividono alcune somiglianze innate come gli approcci architettonici delle API.
Meccanismo di scambio di dati
Entrambi consentono a due componenti software, un client e un server, di comunicare e scambiare dati in base a un insieme condiviso di regole. Queste regole si applicano indipendentemente dal funzionamento interno di ciascun componente software.
Comunicazione basata su HTTP
Entrambi trasmettono i dati tramite il meccanismo di richiesta-risposta HTTP, il protocollo di comunicazione efficiente preferito del Web. Tuttavia, in gRPC, questo è nascosto allo sviluppatore mentre in REST è più evidente.
Flessibilità di implementazione
REST e gRPC possono essere implementati in un'ampia gamma di linguaggi di programmazione. Questa qualità li rende entrambi altamente portabili in tutti gli ambienti di programmazione. Ciò porta a un'interoperabilità ottimale con un supporto quasi universale.
Idoneità per sistemi scalabili e distribuiti
Sia gRPC che REST utilizzano quanto segue:
- Comunicazione asincrona, in modo che client e server possano comunicare senza interrompere le operazioni
- Design stateless, in modo che il server non debba ricordare lo stato del client
Ciò significa che gli sviluppatori possono utilizzare gRPC e REST per creare sistemi resistenti ai guasti con un gran numero di richieste simultanee. È possibile creare sistemi scalabili e distribuiti con più client.
Principi di architettura di gRPC e REST
Sebbene REST e gRPC offrano funzionalità simili, i modelli sottostanti differiscono significativamente nella loro architettura.
Modello di comunicazione
Utilizzando una REST API, un client invia una singola richiesta REST API a un server e il server invia quindi una singola risposta. Il client deve attendere la risposta del server prima di continuare le operazioni. Questo meccanismo è un modello richiesta-risposta ed è una connessione dati unaria (uno a uno).
Al contrario, con gRPC, un client può inviare una o più richieste API al server che possono comportare una o più risposte dal server. Le connessioni dati possono essere unarie (uno-a-uno), streaming su server (uno-a-molti), streaming su client (molti-a-uno) o streaming bidirezionale (molti-a-molti). Questo meccanismo è un modello di comunicazione con risposta dal client ed è possibile perché gRPC è basato su HTTP 2.
Operazioni richiamabili sul server
In un'API gRPC, le operazioni del server richiamabili sono definite da servizi, noti anche come funzioni o procedure. Il client gRPC richiama queste funzioni come se si chiamasse una funzione internamente all'interno di un'applicazione. Ciò è noto come design orientato ai servizi. Ecco un esempio:
createNewOrder(customer_id, item_id, item_quantity) -> order_id
In REST, esiste un set limitato di verbi di richiesta HTTP che il client può utilizzare sulle risorse del server definite da un URL. Il client chiama la risorsa stessa. Questo è noto come design orientato all'entità. Il design orientato alle entità si allinea bene con i metodi di programmazione orientati agli oggetti. Ecco un esempio:
POST /orders <headers> (customer_id, item_id, item_quantity) -> order_id
Sebbene sia possibile progettare le API gRPC con un approccio orientato alle entità, questo non è un vincolo del sistema stesso.
Formato di scambio dati
Con una REST API, le strutture di dati passate tra i componenti software sono in genere espresse in formato di scambio dati JSON. È possibile inviare altri formati di dati come XML e HTML. JSON è facile da leggere e flessibile, sebbene debba essere serializzato e tradotto in un linguaggio di programmazione.
Al contrario, gRPC utilizza il formato Protocol Buffers (Protobuf) per impostazione predefinita, sebbene offra anche il supporto JSON nativo. Il server definisce una struttura dati utilizzando il linguaggio di descrizione dell'interfaccia Protocol Buffer (IDL) in un file di proto-specifica. gRPC quindi serializza la struttura in formato binario e poi la deserializza in qualsiasi linguaggio di programmazione specificato. Questo meccanismo lo rende più veloce rispetto all'uso di JSON, che non viene compresso durante la trasmissione. A differenza di una REST API utilizzata con JSON, i Protocol Buffers non sono leggibili dall'uomo.
Altre differenze principali tra gRPC e REST
Altre differenze principali tra gRPC e REST
Oltre allo stile architettonico, gRPC e REST presentano altre differenze implicite.
Accoppiamento client-server
REST è debolmente associato, il che significa che il client e il server non devono sapere nulla sull'implementazione dell'altro. Questo accoppiamento debole facilita l'evoluzione dell'API nel tempo. Questo perché una modifica nelle definizioni del server non richiede necessariamente una modifica del codice nel client.
gRPC è strettamente accoppiato, il che significa che client e server devono avere accesso allo stesso file proto. Qualsiasi aggiornamento del file richiede aggiornamenti sia sul server che sul client.
Generazione di codice
gRPC offre una selezione integrata di funzionalità di generazione di codice nativo lato client e lato server. Sono disponibili in più linguaggi grazie a protoc, il compilatore di Protocol Buffers. Dopo aver definito la struttura nel file proto, gRPC genera il codice lato client e lato server. La generazione di codice rende lo sviluppo delle API meno dispendioso in termini di tempo.
D'altra parte, REST non offre alcun meccanismo integrato di generazione del codice quindi, se richiedono questa funzionalità, gli sviluppatori devono utilizzare strumenti aggiuntivi di terze parti. Scopri di più sulla generazione di codice.
Streaming bidirezionale
gRPC offre una comunicazione in streaming bidirezionale. Ciò significa che sia il client che il server possono inviare e ricevere più richieste e risposte contemporaneamente su un'unica connessione.
REST non offre questa funzionalità.
Quando usare gRPC e REST
REST è attualmente l'architettura API più popolare per servizi Web e architetture di microservizi. La popolarità di REST è dovuta alla sua semplice implementazione e mappatura della struttura dei dati, alla leggibilità e alla flessibilità. È facile per i nuovi programmatori iniziare a sviluppare API RESTful per le loro applicazioni, sia per lo sviluppo di servizi Web che per microservizi interni.
Ecco alcuni casi d'uso per una REST API:
- Architetture basate sul Web
- API rivolte al pubblico per una facile comprensione da parte di utenti esterni
- Semplici comunicazioni di dati
gRPC, a differenza di REST, è stato progettato specificamente per consentire agli sviluppatori di creare API ad alte prestazioni per architetture di microservizi in data center distribuiti. È più adatto per sistemi interni che richiedono streaming in tempo reale e carichi di dati di grandi dimensioni. gRPC è anche adatto per architetture di microservizi che comprendono diversi linguaggi di programmazione quando è improbabile che l'API cambi nel tempo.
Un'API gRPC è migliore per questi casi d'uso:
- Sistemi ad alte prestazioni
- Carichi di dati elevati
- Applicazioni in tempo reale o in streaming
Una nota sullo sviluppo di software Web
Sebbene HTTP sia il protocollo Web principale, esistono diverse versioni di HTTP con diversi gradi di adozione tra browser Web e server Web.
Un'API gRPC utilizza sempre HTTP 2 e una REST API utilizza in genere HTTP 1.1, che non è lo stesso protocollo HTTP. Sebbene HTTP 2 sia ora un protocollo Web comune, a differenza di HTTP 1.1 non ha il supporto universale per i browser. Questo supporto limitato del browser può rendere gRPC un'opzione meno attraente per gli sviluppatori che desiderano supportare le applicazioni Web.
Riepilogo delle differenze tra gRPC e REST
| API gRPC |
REST API |
|
| In cosa consiste? |
Un sistema per creare e utilizzare API basato sul modello di comunicazione client-server RPC (Remote Procedure Call). |
Un insieme di regole che definisce lo scambio di dati strutturati tra un client e un server. |
| Approccio progettuale |
Design orientato ai servizi. Il client chiede al server di eseguire un servizio o una funzione che può influire o meno sulle risorse del server. |
Design orientato all'entità. Il client chiede al server di creare, condividere o modificare le risorse. |
| Modello di comunicazione |
Opzioni multiple come unario, un server per molti client, un client per molti server e molti client per molti server. |
Unario. Un singolo client comunica con un singolo server. |
| Implementazione |
Per funzionare, richiede il software gRPC sia sul lato client che sul lato server. |
È possibile implementarlo sul lato client e server in un'ampia varietà di formati senza la necessità di software comuni. |
| Accesso ai dati |
Chiamate di servizio (funzione). |
Più endpoint sotto forma di URL per definire le risorse. |
| Dati restituiti |
Nel tipo di ritorno fisso del servizio, come definito nel file di Protocol Buffers. |
In una struttura fissa (tipicamente JSON), definita dal server. |
| Accoppiamento client-server |
Strettamente accoppiato. Sia il client che il server richiedono lo stesso file di Protocol Buffers che definisce il formato dei dati. |
Debolmente accoppiato. Client e server non sono a conoscenza dei dettagli interni. |
| Generazione automatica di codice |
Funzionalità integrata. |
Richiede strumenti di terze parti. |
| Streaming bidirezionale |
Presente. |
Non presente. |
| Ideale per |
Architetture di microservizi ad alte prestazioni o con uso intensivo di dati. |
Origini dati semplici in cui le risorse sono ben definite. |
In che modo AWS può supportare i tuoi requisiti gRPC e REST?
Amazon Web Services (AWS) offre una gamma di servizi e strumenti per aiutare i progettisti di API a creare, eseguire e gestire applicazioni e servizi moderni basati su API. Per ulteriori informazioni, leggi come creare applicazioni moderne su AWS.
Ecco alcuni esempi di offerte AWS in grado di supportare i tuoi requisiti API:
- Gateway Amazon API consente agli sviluppatori di creare, pubblicare e gestire API su larga scala. Con Gateway API, puoi creare API RESTful ottimizzate per architetture di microservizi containerizzate e applicazioni Web.
- Elastic Load Balancing (ELB) distribuisce il traffico di rete per migliorare la scalabilità delle applicazioni. Può instradare e bilanciare il carico del traffico gRPC tra microservizi o tra client e servizi abilitati a gRPC. Ciò consente l'introduzione senza problemi della gestione del traffico gRPC nelle architetture senza modificare alcuna infrastruttura sottostante sui clienti o sui servizi dei clienti.
- Amazon Virtual Private Cloud (Amazon VPC) Lattice è un servizio di rete di applicazioni che connette, monitora e protegge costantemente le comunicazioni tra i tuoi servizi. Scala automaticamente le risorse di calcolo e di rete per supportare carichi di lavoro HTTP, HTTPS e gRPC a larghezza di banda elevata.
Inizia subito a utilizzare gRPC e REST su AWS creando un account.
