Programmazione · web · API

gRPC vs REST

Quando progetti la comunicazione tra due programmi in rete, il bivio moderno è REST vs gRPC. Entrambi espongono funzionalità via HTTP, ma fanno scommesse opposte: REST privilegia la semplicità leggibile e universale; gRPC l’efficienza veloce, tipizzata, binaria. Questa guida li confronta onestamente su formato, prestazioni, streaming, supporto browser e tooling – e quando scegliere ciascuno. (Nuovo alle API? Inizia da cos’è un’API.)

La differenza fondamentale

• REST – uno stile di architettura su HTTP: risorse a URL, verbi HTTP (GET/POST/PUT/DELETE), di solito JSON. Leggibile, senza stato, universale.
• gRPC – un framework di chiamate a procedura remota: chiami metodi (come funzioni locali) definiti in un contratto .proto, scambiando Protocol Buffers binari su HTTP/2.

REST è orientato alle risorse («recupera questa cosa»); gRPC è orientato all’azione («chiama questo metodo»). REST è testo; gRPC è binario e fortemente tipizzato.

Prestazioni e trasporto

I Protocol Buffers di gRPC sono binario compatto, inviato su connessioni HTTP/2 multiplexate – payload più piccoli, meno parsing, più chiamate su una connessione. Il JSON di REST su HTTP/1.1 è più pesante e verboso, sebbene molto ottimizzato e cacheabile. Per il traffico tra servizi ad alto volume, l’efficienza di gRPC è reale; per una tipica API pubblica, REST spesso basta e sfrutta la cache HTTP gratuita.

Streaming, contratti e codegen

gRPC supporta nativamente lo streaming bidirezionale (client, server e in entrambe le direzioni), ideale per il tempo reale e l’alto throughput. Il suo file .proto è un contratto rigoroso da cui client e server vengono generati in molti linguaggi – perfetto per backend poliglotti e per rilevare incompatibilità in fase di compilazione. REST non ha un contratto integrato (OpenAPI/Swagger va aggiunto) e lo streaming è limitato (SSE/WebSocket vanno aggiunti), ma questa flessibilità è anche ciò che lo rende facile da iniziare.

Supporto browser e ubiquità

Questo è il terreno di REST. Qualsiasi browser chiama un’API REST tramite fetch; ogni linguaggio e strumento la comprende; la si esegue il debug con curl e si legge il JSON. I browser non parlano gRPC nativo – serve gRPC-Web più un proxy (es. Envoy), che aggiunge parti in movimento. Se i tuoi frontend web sono i consumatori principali, REST (o GraphQL) è più semplice.

Come scegliere

• Scegli REST per API pubbliche, client browser, CRUD semplice e quando contano leggibilità, ubiquità e cache HTTP.
• Scegli gRPC per chiamate interne tra servizi dove contano prestazioni, bassa latenza, streaming e contratto rigorosamente tipizzato (microservizi, tempo reale, poliglotta).
• Entrambi – REST/GraphQL al confine per i client, gRPC tra i servizi interni: un’architettura molto diffusa.

Domande frequenti

Qual è la differenza tra gRPC e REST?

REST è uno stile architetturale per API web basato su HTTP, che scambia di solito JSON leggibile tramite URL di risorse. gRPC è un framework RPC ad alte prestazioni che gira su HTTP/2 e scambia Protocol Buffers binari, definiti da un contratto .proto rigoroso. In breve: REST è orientato alle risorse, testuale e universale; gRPC è orientato all’azione (al metodo), binario, tipizzato e veloce. Entrambi risolvono lo stesso problema – programmi che comunicano in rete – con compromessi diversi.

gRPC è più veloce di REST?

In genere sì per il traffico tra servizi. gRPC invia Protocol Buffers binari compatti su connessioni HTTP/2 multiplexate: payload più piccoli, meno overhead rispetto a JSON su HTTP/1.1 e streaming bidirezionale. Il divario conta soprattutto per i microservizi interni ad alto volume; per un’API pubblica poco carica, REST + cache HTTP è spesso più che sufficiente.

Si può usare gRPC in un browser?

Non direttamente. I browser non parlano gRPC nativo perché non espongono il controllo HTTP/2 di basso livello di cui gRPC ha bisogno. Si usa gRPC-Web con un proxy (es. Envoy) come ponte, il che aggiunge complessità e limita alcune funzioni (come lo streaming client). REST invece funziona nativamente da qualsiasi browser tramite fetch. Se la tua API è consumata soprattutto da frontend web, REST (o GraphQL) è più semplice.

Quando usare gRPC invece di REST?

Scegli gRPC per la comunicazione interna tra servizi dove contano prestazioni, bassa latenza, streaming e un contratto rigorosamente tipizzato – microservizi, dati in tempo reale, backend poliglotti. Scegli REST per API pubbliche, client browser, CRUD semplice di risorse e quando contano leggibilità, ubiquità e cache HTTP gratuita. Molti sistemi usano entrambi: REST/GraphQL al confine per i client, gRPC tra i servizi interni.

In sintesi

REST e gRPC non sono rivali ma strumenti per compiti diversi. REST vince su universalità, supporto browser, leggibilità e cache – l’impostazione giusta per API pubbliche e web. gRPC vince su velocità, streaming e contratti tipizzati – l’impostazione giusta per microservizi interni ad alte prestazioni. Scegli in base ai tuoi chiamanti e al tuo traffico, e non esitare a usare entrambi.