gRPC e REST a confronto

Nel grande atlante di internet, le application programming interface (API) sono le strade che collegano città, paesi, spiagge e altre destinazioni. Le API consentono alle applicazioni software di comunicare tra loro per scambiare dati, caratteristiche e funzionalità. Un report Imperva del 2023 ha rilevato che circa il 71% del traffico internet era costituito da chiamate API, dimostrando quanto questa tecnologia sia fondamentale per il funzionamento delle applicazioni e delle aziende moderne.

Non c'è da stupirsi che capire come creare un'API sia un'abilità fondamentale per la maggior parte degli sviluppatori. Ma, come si addice a un'infrastruttura così importante, esistono diverse varietà.

Per estendere la nostra metafora, un'autostrada a 12 corsie non è "migliore" di una strada a corsia singola: l'autostrada distruggerebbe il tessuto di un quartiere urbano e la strada a una corsia sarebbe un disastro in una zona ad alto traffico. I diversi stili architettonici per la creazione di API, come REST e gRPC, sono uguali: ognuno ha punti di forza e di debolezza e comprenderli è fondamentale per la creazione di un'infrastruttura sana.

Representational State Transfer, o REST, è un insieme di principi di progettazione (o vincoli architettonici): interfaccia uniforme, disaccoppiamento client-server, statelessness, cacheability, architettura di sistema a più livelli e codice on demand (opzionale). Le API create utilizzando questi principi sono denominate API REST o API RESTful.

Le API REST possono utilizzare vari linguaggi di programmazione e formati di dati, a condizione che siano conformi ai principi REST. Si tratta del metodo più comune di costruire un'API.

Le API REST utilizzano richieste HTTP (note anche come metodi HTTP) come GET, POST, PUT e DELETE per eseguire funzioni di database standard. Queste operazioni vengono utilizzate per creare, leggere, aggiornare ed eliminare record di risorse e sono spesso denominate "CRUD". Le risorse lato server sono identificate da URL chiamati endpoint.

Ad esempio, un'API REST utilizzerà una richiesta GET per recuperare un record. Una richiesta POST crea un nuovo record. Una richiesta PUT aggiorna un record e una richiesta DELETE ne elimina uno. Tutti i metodi HTTP possono essere utilizzati nelle chiamate API. Un'API REST ben progettata è simile a un sito web in esecuzione in un browser web con funzionalità HTTP integrata.

Le informazioni sulle risorse possono essere inviate a un client in molti formati di messaggistica, tra cui JavaScript Object Notation (JSON), HTML, XLT, Python, PHP o testo semplice. Il formato JSON è popolare perché è leggibile sia dagli esseri umani che dalle macchine e perché è indipendente dal linguaggio di programmazione.

Scopri di più su REST e GraphQL

Supporto per browser: poiché le API REST utilizzano HTTP/1.1 e metodi HTTP standard, oltre a formati come XML e JSON, sono compatibili con i browser. 

Facilità d'uso: grazie alla sua semplicità e popolarità, REST è ampiamente considerato più facile da capire, soprattutto per i principianti. Strumenti, tutorial e guide sono disponibili in abbondanza su GitHub e altrove.

Flessibilità: si ritiene che le API REST abbiano un accoppiamento debole tra client e server. Questa flessibilità consente modifiche più semplici e rapide: una modifica può essere apportata a uno dei due lati senza richiedere una modifica all'altro.

Ecosistema robusto: le API REST hanno un numero significativo di strumenti e un ampio supporto e documentazione. La specifica OpenAPI, o OAS, ad esempio, fornisce una definizione standard di settore dei parametri e delle funzionalità di un'API REST. L'ultima versione di OAS, OAS 3.1, include la piena compatibilità con lo schema JSON, l'identificazione standardizzata che utilizza l'identificatore SPDX e altro ancora.

Affidamento su HTTP/1.1: Sebbene l'uso di HTTP/1.1 da parte di REST offra il supporto universale del browser e alcune personalizzazioni nelle intestazioni, priva anche le API REST di alcuni dei vantaggi del nuovo HTTP/2. Questi vantaggi mancanti includono lo streaming bidirezionale; REST supporta solo lo streaming unario, in cui una richiesta è seguita da una risposta.

Più lento e meno efficiente: come per HTTP/1.1, la dipendenza di REST da formati come XML e JSON presenta pro e contro. Questi formati sono leggibili dall'uomo, il che è ottimo, ma sono anche file relativamente grandi, il che comporta una trasmissione più lenta.

Richiede strumenti aggiuntivi: l'ecosistema REST potrebbe essere robusto, ma deve esserlo, poiché alcune caratteristiche non sono integrate nell'architettura. La generazione di codice, ad esempio, è disponibile sotto forma di plug-in per REST, ma si tratta comunque di un passaggio in più, con una complicazione aggiunta.

gRPC è un framework open source che Google ha inizialmente sviluppato come implementazione specifica di Remote Procedure Call, o RPC. Ora è gestito dalla Cloud Native Computing Foundation (CNCF).

gRPC potrebbe essere l'acronimo di "Google Remote Procedure Call" come non esserlo, in quanto gli sviluppatori sostengono invece che si tratti dell'acronimo di "gRPC Remote Procedure Call", o altre possibilità ancora. In ogni caso, gRPC, come altre RPC, consente alle chiamate remote di apparire e funzionare come chiamate locali.

Come modello per l'interazione client/server, RPC viene spesso utilizzato nell'api development. In un modello RPC, il client interagisce con un intermediario comunemente denominato stub. Questo stub converte i dati per la trasmissione e, una volta ricevuti i risultati richiesti dal server, li riconverte nel formato originale per il client. Esistono molti tipi diversi di framework RPC, tra cui XML-RPC e JSON-RPC.

Questi framework RPC sono leggeri, relativamente semplici da usare e offrono benefici come lo sviluppo semplificato e l'astrazione delle comunicazioni di rete. Tuttavia, ambienti come le architetture di microservizi e i sistemi con carichi di dati elevati spesso richiedono un framework con prestazioni più elevate e gRPC è stato sviluppato per soddisfare tale esigenza.

gRPC usa un linguaggio IDL (Interface Definition Language) denominato Protocol Buffers (Protobuf) per serializzare i dati strutturati in file binari. Poiché il formato binario è più compatto di JSON o XML, consente il trasferimento di carichi utili più grandi a velocità più elevate.

gRPC utilizza anche HTTP/2, che consente lo streaming bidirezionale e rende gRPC una scelta valida per le API in ambienti distribuiti (in particolare quelli che richiedono comunicazioni in tempo reale), architetture di microservizi, applicazioni di streaming e la connessione di dispositivi Internet of Things (IoT).

Velocità: gRPC, tramite Protobuf, serializza e deserializza i dati provenienti da molti linguaggi diversi, tra cui Java, Python, Ruby e altri, in un payload binario per la trasmissione. Questo codice è leggero, quindi i tempi di trasmissione e la latenza nello scambio di dati sono ridotti con le API gRPC.

Generazione di codice: gRPC include un compilatore Protobuf chiamato [protoc], che offre caratteristiche di generazione di codice nativo. Una volta che la struttura dei dati è definita in un file .proto gRPC può generare codice sia lato client che lato server.

Supporto HTTP/2: basandosi sul protocollo di trasporto HTTP/2, gRPC supporta vari tipi di streaming. Ad esempio, supporta lo streaming bidirezionale, in cui il client e il server possono inviare messaggi in modo indipendente in un flusso di lettura/scrittura, oltre allo streaming lato client e lato server.

Intercettori: gRPC supporta il middleware noto come intercettori, che consentono di aumentare le funzionalità. Gli intercettori possono essere installati per implementare la sicurezza, l'autenticazione, l'analisi delle metriche e altro ancora.

Annullamento e timeout: gRPC supporta l'annullamento, altrimenti noto come timeout o scadenza: un tempo specificato dopo il quale la chiamata sarà annullata.

Novità e ed ecosistema: sebbene gRPC includa caratteristiche extra come la generazione di codice, è un'architettura relativamente nuova, che è stata inizialmente pubblicata solo nel 2016. Questa novità ha reso la documentazione e il supporto limitati rispetto agli stili architettonici più vecchi.

Curva di apprendimento ripida: alcuni sviluppatori ritengono che gRPC abbia una curva di apprendimento più ripida rispetto a REST. La serializzazione dei dati binari garantisce una comunicazione efficiente, ma non è leggibile dall'uomo.

Mancanza di supporto per il browser: poiché i browser web non supportano nativamente il protocollo gRPC, non è possibile chiamare direttamente un servizio gRPC da un'applicazione basata su browser. Un modo per ovviare a questo problema è utilizzare un proxy come gRPC-Web. gRPC-Web agisce essenzialmente come un livello di traduzione tra il protocollo HTTP e gRPC di un browser.

REST e gRPC hanno molti elementi in comune e sono entrambi utilizzati per costruire sistemi scalabili. Le somiglianze includono:

Architettura client/server: gRPC e REST sono entrambe architetture client/server con un formato richiesta-risposta che consente a client e server di comunicare e scambiare dati. In questa architettura, un client invia una richiesta e il server risponde richiedendo i dati o eseguendo un'azione richiesta.

Indipendente dalla piattaforma: gRPC e REST consentono la comunicazione tra servizi basati su piattaforme diverse con sistemi operativi diversi.

Apolidia: sia REST che gRPC sono considerati senza stato, il che significa che ogni richiesta include tutte le informazioni necessarie per completarla. Il server non ha bisogno di memorizzare alcuna informazione sulle richieste precedenti.

Supporto linguistico: entrambi gli stili architettonici sono indipendenti dal linguaggio, il che significa che queste API possono essere utilizzate da applicazioni scritte in vari linguaggi di programmazione. Questa qualità rende entrambi portabili in tutti gli ambienti di programmazione.

Utilizzo di HTTP: sia REST che gRPC si basano sulla comunicazione basata su HTTP. Tuttavia, gRPC utilizza HTTP/2, mentre REST si basa su HTTP/1.1. Inoltre, gRPC astrae il protocollo di comunicazione HTTP/2 sottostante, mentre la comunicazione HTTP è meno astratta in REST.

Le differenze principali tra REST e gRPC possono aiutare gli sviluppatori a decidere quale sia la migliore per l'API che stanno creando. Queste differenze includono:

Formato dei dati: le API REST utilizzano principalmente formati basati sul testo, come JSON e XML. gRPC utilizza Protobuf per codificare i dati in formato binario.

Modello di comunicazione: REST supporta solo la comunicazione unaria, ovvero una richiesta seguita da una risposta. gRPC ne supporta altri tipi, tra cui lo streaming bidirezionale (sia il client che il server si scambiano in modo indipendente), lo streaming del server (una singola richiesta attiva più risposte) e lo streaming del client (più richieste danno luogo a una singola risposta).

Modello di progettazione: gRPC ha un design orientato ai servizi, in cui le operazioni del server richiamabili sono definite come servizi o funzioni. In REST, la progettazione è orientata alle risorse, in cui i metodi HTTP vengono utilizzati per accedere alle risorse del server tramite endpoint definiti da URL.

Accoppiamento: il client e il server di gRPC sono strettamente collegati, il che significa che sia il client che il server devono avere accesso allo stesso file di prototipazione middleware. Qualsiasi cambiamento in uno richiede un cambiamento nell'altro. REST è accoppiato in modo libero. Questa indipendenza significa che le modifiche in un componente non influiscono sull'altro.

Generazione di codice: gRPC offre la generazione di codice integrata; REST non lo fa, anche se sono disponibili plug-in.

Implementazione: REST non richiede un software specifico e supporta i browser. gRPC richiede un software specifico sia sul lato server che su quello client.

REST è una scelta popolare di progettazione di API per un motivo; la sua semplicità, ampia compatibilità e versatilità lo rendono una scelta eccellente per molte applicazioni. Per le API pubbliche, REST è spesso la scelta più sensata, in quanto è più ampiamente utilizzato e spesso più facilmente comprensibile. Molti sviluppatori hanno più familiarità con REST e potrebbero disporre di un'infrastruttura significativa specifica per REST, inclusi server, strumenti di API management, strumenti di sviluppo e vari strumenti di test.

REST supporta anche il caching integrato, ovvero la capacità di memorizzare i dati a cui si accede di frequente, localmente o tramite un proxy. La cache può migliorare significativamente la velocità e l'efficienza, ma deve anche includere varie informazioni di validazione, autenticazione e scadenza.

REST è generalmente preferito anche per i servizi web e le API web, grazie al supporto per HTTP/1.1 e al supporto universale dei browser. In genere è preferibile a gRPC per comunicazioni di dati più semplici. L'accoppiamento debole e la ridotta complessità possono migliorare la scalabilità dell'architettura di sistema e contribuire a rendere un ambiente più flessibile nel tempo. Tuttavia, questa adattabilità ha un costo in termini di prestazioni. 

gRPC è un'architettura relativamente nuova, con gli sviluppatori che ne apprezzano sempre più la velocità, l'efficienza e gli strumenti integrati. Viene spesso utilizzato per applicazioni di streaming in tempo reale e API complesse che richiedono prestazioni elevate e la gestione di elevati carichi di dati nei sistemi distribuiti. Sebbene sia più complesso di REST, l'uso di HTTP/2 e Protobuf offre a gRPC una maggiore scalabilità delle prestazioni. 

gRPC è adatto per le architetture di microservizi, poiché la sua capacità di trasmettere dati bidirezionali in tempo reale consente ai diversi servizi all'interno di un'applicazione di inviare e ricevere contemporaneamente e indipendentemente. Viene supportato anche nelle applicazioni mobile grazie alla trasmissione dati rapida e compatta e perché è meno probabile che le applicazioni mobile si basino su un browser.

gRPC è ideale anche per connettere elementi IoT alle API di backend, perché i suoi carichi utili compatti, la bassa latenza e l'efficienza delle prestazioni si combinano bene con la tecnologia a basso consumo.