Quale scegliere per il tuo prossimo progetto [2023]

Incontrerai spesso REST e gRPC quando hai a che fare con le API. Anche se Rest ha dominato questo campo per molti anni, gRPC si sta dimostrando un degno concorrente.

Rest e gPRC sono due modi diversi per progettare un’API. Le API fungono da ponte di comunicazione tra servizi che possono rappresentare sistemi complessi residenti in computer diversi o scritti in lingue diverse.

Questo articolo introdurrà sia Rest che gRPC, condividerà le loro somiglianze, differenze e dove utilizzare ciascuno.

Che cos’è il riposo?

Riposo (Representational State Transfer) è un approccio software architetturale che detta le regole su come i componenti software scambiano i dati. Rest si basa sul protocollo di comunicazione standard del Web, HTTP.

Tutte le API basate sullo stile architetturale REST sono chiamate API RESTful. D’altra parte, i servizi Web che seguono la progettazione dell’architettura REST sono noti come servizi Web RESTful.

Lo stile architettonico REST è guidato da questi principi;

  • Interfaccia uniforme: il server dovrebbe trasferire i dati in un formato standard. Tuttavia, i dati trasportati possono essere in un formato diverso dalla rappresentazione interna della risorsa dell’applicazione server.
  • Apolidia: il server deve completare ogni richiesta del client in modo indipendente, indipendentemente dalle richieste precedenti. Le richieste client per le risorse possono essere in qualsiasi ordine e ogni richiesta è isolata dal resto.
  • Sistema a strati: presenta uno strato di intermediari autorizzati tra il server e il client. Il client può connettersi con questi intermediari autorizzati e ricevere comunque risposte dal server.
  • Cacheability: alcune risposte vengono archiviate su un intermediario o sul client per migliorare i tempi di risposta.
  • Codice su richiesta: i server personalizzano o estendono temporaneamente le funzionalità del client trasferendo il codice di programmazione del software al client.

Vantaggi del RIPOSO

  • Scalabile: le API REST sono note per la loro scalabilità in quanto ottimizzano le interazioni client-server. La memorizzazione nella cache e l’assenza di stato sono le caratteristiche principali che riducono il carico del server.
  • Flessibile: le API RESTful offrono una totale separazione client-server. Tali servizi semplificheranno e semplificheranno vari componenti del server, che possono evolversi in modo indipendente.
  • Indipendenza: puoi scrivere applicazioni server e client in diversi linguaggi di programmazione senza influire sulla progettazione dell’API.

Casi d’uso di Rest

  • API web
  • servizi web
  • Architettura dei microservizi

Cos’è gRPC?

gRPC è un framework RPC (Remote Procedure Call) che può essere eseguito in qualsiasi ambiente. Questo framework open source è progettato come protocollo ad alte prestazioni in grado di connettere in modo efficiente i servizi tra e nei data center.

Un’app client può chiamare un metodo su un’app server su un computer diverso come se fosse un oggetto locale. Con gRPC, definisci un servizio e specifichi i metodi che puoi chiamare in remoto con i relativi parametri e tipi restituiti.

gRPC offre supporto per il controllo dell’integrità, l’autenticazione, il bilanciamento del carico e la traccia collegabili. Questo framework utilizza HTTP 2 e Protocol Buffers per la trasmissione dei dati. Quando i dati vengono scambiati, viene chiamata una procedura invece di un URL di risorsa

Vantaggi di gRPC

  • Scalabile: gRPC consente di installare ambienti di runtime con un singolo comando e iniziare a scalare milioni di RPC al secondo.
  • Definizione semplice del servizio: utilizza i buffer di protocollo per definire i tuoi servizi e farli funzionare.
  • Multipiattaforma: questo framework genera stub client e server idiomatici per diverse piattaforme e linguaggi.
  • Streaming bidirezionale e autenticazione integrata.

Casi d’uso di gRPC

  • API web
  • servizi web
  • Applicazioni in streaming
  • Microservizi Comunicazione

Somiglianze tra REST e gRPC

  • Meccanismo di scambio dati: entrambi i progetti architetturali consentono a server e client di scambiare dati. Tuttavia, questi dati vengono condivisi in base a determinate regole.
  • Adatto a sistemi scalabili e distribuiti: la comunicazione asincrona e il design senza stato di REST e gRPC semplificano la scalabilità delle loro API.
  • Utilizza la comunicazione basata su HTTP: entrambi utilizzano HTTP, il protocollo di comunicazione preferito del web.
  • Flessibile: puoi utilizzare REST e gRPC con diversi linguaggi e tecnologie di programmazione.

REST vs. gRPC: confronto approfondito

I servizi REST e gRPC differiscono nei seguenti modi;

Scambio di dati

Nelle API REST, i dati passati da un componente software a un altro devono essere espressi in formato JSON. JSON deve essere serializzato e tradotto in un linguaggio di programmazione per lo scambio di dati. Tuttavia, le API Rest possono anche scambiare formati di dati come HTML e XML.

gRPC, per impostazione predefinita, utilizza il formato Protocol Buffers. Tuttavia, supporta nativamente anche JSON. I buffer di protocollo non sono leggibili dall’uomo. Il server utilizza il linguaggio di descrizione dell’interfaccia Protocol Buffer per definire una struttura di dati. gPRC quindi serializza la struttura dei dati in un formato binario. Quindi deserializzerà i dati in qualsiasi linguaggio di programmazione specificato.

Modello di comunicazione

In REST, un client invia una singola richiesta a un server; il server quindi invia una risposta in risposta. Il client deve attendere la risposta del server prima di continuare le operazioni. È un modello di richiesta-risposta.

In gRPC, un client può inviare richieste al server singole o multiple, che generano rispettivamente risposte singole o multiple. Le connessioni dati possono essere molti-a-molti, molti-a-uno, uno-a-molti o uno-a-uno. gRPC utilizza un modello di comunicazione di risposta del client.

Generazione del codice

gRPC dispone di funzionalità di generazione di codice lato server e lato client native integrate. È possibile trovare queste funzionalità in diverse lingue per gentile concessione del compilatore Protocol Buffers. gRPC genera il codice lato server e lato client dopo aver definito la struttura nel file proto.

REST non dispone di funzionalità di generazione del codice integrate. Se hai bisogno di questa funzione, puoi utilizzare strumenti di terze parti.

Protocollo HTTP

Le API REST utilizzano HTTP 1.1. Per inviare una richiesta su un servizio REST, è necessario un URL della risorsa. HTTP 1 invia informazioni tra un computer e un server Web. L’URL della risorsa nel servizio REST è visibile al client. I progettisti dell’API controllano la struttura degli URL delle risorse.

gRPC utilizza HTTP 2. Questa versione HTTP è stata introdotta nel 2015 ed è utilizzata in browser come Internet Explorer, Safari e Chrome. A differenza di HTTP 1, che mantiene tutto in testo normale, questo formato più recente utilizza l’incapsulamento del formato binario, offrendo più opzioni di consegna dei dati e velocizzando l’intero processo.

Struttura dei dati del carico utile

REST utilizza XML o JSON per inviare e ricevere dati. JSON è il formato più utilizzato per l’invio di dati dinamici in REST in quanto è flessibile e non richiede alcuna struttura. Anche i dati JSON sono leggibili dall’uomo. L’unico problema con JSON non è così veloce in quanto deve essere serializzato e tradotto durante il trasferimento dei dati.

gRPC utilizza i buffer di protocollo per serializzare i dati del payload. Questo è un formato altamente compresso che riduce i dati dei messaggi. Questo framework utilizza Protobuf per convertire automaticamente i messaggi fortemente tipizzati nei linguaggi di programmazione del client e del server.

Supporto browser

REST è supportato su tutti i browser in quanto utilizza HTTP 1.1. Questo lo rende una scelta perfetta per i servizi Web e le API.

gRPC ha un supporto limitato per i browser poiché è basato su HTTP 2. Per supportare tutti i browser, è necessario aggiungere gRPC-web come livello proxy. Per questo motivo, gRPC viene adottato principalmente per i sistemi interni.

Accoppiamento client-server

REST è un progetto architettonico liberamente accoppiato. Significa che il client e il server non devono conoscere le reciproche implementazioni. Questa funzionalità semplifica l’evoluzione di un’API RESTful nel tempo, poiché non è necessario modificare il codice client quando si modificano le definizioni del server.

gRPC è un framework strettamente accoppiato in cui il server e il client devono avere accesso allo stesso file proto. Se è necessario apportare modifiche al file, è necessario aggiornare anche il server e il client.

Riposo vs gRPC

CaratteristicaRESTgRPCHTTp protocolHTTP 1.1HTTP 2Browser supportSupporta tutti i browser poiché utilizza HTTP 1.1 Lesser browser support poiché utilizza HTTP 2Generazione del codiceUtilizza strumenti di terze partiFunzionalità di generazione del codice integrateApproccio di progettazione Progettazione orientata all’entitàApproccio orientato al servizioAccesso ai datiURL delle risorseChiamate di servizioStreaming dati bidirezionaleNon disponibileDisponibileImplementazioneNon è necessario alcun software comune per l’implementazione REST sul lato client o lato server Il software RPC è necessario sia sul lato client che su quello server. Modello di comunicazioneUn singolo client comunica con un singolo serverPiù modelli di comunicazione come un client invia richieste a più server, un server che comunica con più client o un server che comunica con un client.

Quando usare REST

Le API RESTful e i servizi Web sono molto popolari. I servizi RESTful sono facili da implementare, strutturare i dati, flessibili e leggibili. È possibile utilizzare REST nelle seguenti istanze;

  • Architetture basate sul Web: puoi creare API Web, mobili e multipiattaforma utilizzando la progettazione dell’architettura REST.
  • Comunicazioni di dati semplici: REST utilizza JSON, un formato di dati di facile lettura.
  • API rivolte al pubblico: se intendi che il pubblico utilizzi i dati e utilizzi la tua API, REST sarà una buona scelta grazie alla sua funzionalità di leggibilità.

Quando usare gRPC

gRPC non è così popolare come i servizi RESTful. Tuttavia, ha anche caratteristiche uniche che lo faranno risaltare nelle seguenti applicazioni;

  • Sistemi multilingue: gRPC si adatta alle architetture di microservizi scritte in diversi linguaggi di programmazione e dove è improbabile che l’API cambi.
  • Connessioni di microservizi: funzionalità come lo streaming bidirezionale e il basso supporto del browser rendono gRPC una buona scelta per le API interne.
  • Reti di streaming in tempo reale: puoi usare gRPC con servizi interni che gestiscono carichi di dati di grandi dimensioni e richiedono streaming in tempo reale.

Opinione degli autori

Anche se gRPC ha alcune caratteristiche specifiche che possono eclissare REST in applicazioni come Internet of Things, quest’ultimo vince grazie alla sua leggibilità, flessibilità e ampia adozione. Il supporto del browser inferiore di gRPC lo rende una scelta non così buona per gli sviluppatori che desiderano creare servizi Web.

Il supporto universale per i servizi RESTful rende REST lo stile di architettura API ideale per integrazioni web e microservizi.

Conclusione

REST e gRPC sono tra i molti stili di architettura API che puoi scegliere quando crei la tua prossima API. La scelta finale dipenderà dal prodotto che desideri costruire. I servizi RESTful si adatteranno perfettamente alla creazione di API rivolte al pubblico, mentre gRPC è una buona scelta per servizi come le applicazioni mobili che non richiedono il supporto del browser.

Successivamente, consulta il nostro articolo su come creare gRPC da zero utilizzando Java.