Risposta.

La scelta dello stile architetturale dell'API dipende dai requisiti di scalabilità, velocità, flessibilità, compatibilità e specificità dei consumatori dell'API.

• REST: Adatto per la maggior parte delle integrazioni interne ed esterne grazie alla semplicità (HTTP, JSON), operazioni idempotenti, caching e ampia supporto negli strumenti.
• gRPC: Utilizzato per alte prestazioni e streaming bidirezionale, bassa latenza, schema rigoroso (Protobuf). Ottimo per servizi interni e microservizi dove i requisiti di prestazioni sono superiori a quelli di compatibilità.
• GraphQL: Permette al client di scegliere la propria struttura dei dati. Ottimo per client mobile esterni e front-end quando serve flessibilità e riduzione del traffico.

Esempio di codice (servizio gRPC in Go):

// Descrizione del protocollo
service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply) {}
}

// Implementazione
func (s *server) SayHello(ctx context.Context, req *pb.HelloRequest) (*pb.HelloReply, error) {
  return &pb.HelloReply{Message: "Hello " + req.Name}, nil
}

Caratteristiche chiave:

• Diversi stili architetturali (REST, gRPC, GraphQL) risolvono problemi diversi
• gRPC è migliore per API interne con elevate esigenze di velocità e tipizzazione
• GraphQL è ottimale per API pubbliche complesse con molte variazioni di richiesta e grande numero di consumatori front-end

Domande trabocchetto.

È possibile utilizzare GraphQL per sostituire tutte le API REST o gRPC?

No, GraphQL non è sempre razionale — complica il caching, il logging, rende difficile la protezione dell'API e può essere eccessivo per compiti semplici, dove REST o gRPC sono più semplici e affidabili.

Può REST garantire una tipizzazione rigorosa?

Solo parzialmente. REST è definito dalla coerenza dei contratti (Swagger/OpenAPI), ma per sua natura lavora con formati non rigorosi (JSON/HTTP), mentre gRPC fornisce una tipizzazione statica rigorosa grazie allo schema Protobuf.

In quali casi gRPC non è raccomandato per API pubbliche?

gRPC è meno compatibile con i browser e si integra male con l'infrastruttura HTTP/1.1 (ad esempio, proxy, firewall). Per API web pubbliche, è meglio REST o GraphQL.