API REST e API GraphQL: un confronto

Per integrare le applicazioni in modo rapido e su scala, le API sono realizzate utilizzando protocolli e/o specifiche per definire la semantica e la sintassi dei messaggi trasmessi. Queste specifiche costituiscono l'architettura dell'API.

Nel corso del tempo sono stati pubblicati diversi stili di architettura API. Ognuno di essi ha i propri modelli di standardizzazione dello scambio di dati. La scelta solleva infiniti dibattiti su quale sia l'architettura migliore.

In questo articolo parliamo di API REST e API GraphQL.

 

API REST

L'architettura REST o RESTful è il risultato di una tesi di dottorato del 2000 di Roy Fielding, un informatico statunitense. Il suo protocollo REST si basa su sei principi:

 

1. Architettura client-server
2. Stateless
3. Caching
4. Uniform Interface
5. Layered System
6. Code on demand

 

Di questi principi, è soprattutto il principio stateless a risultare essenziale per la struttura delle interfacce programmate con REST (API REST). Ciò significa che ogni messaggio REST contiene tutte le informazioni necessarie per la sua comprensione. Sebbene REST sia fondamentalmente compatibile con qualsiasi protocollo o formato di file, di solito viene utilizzato il protocollo HTTP. La trasmissione dei dati avviene solitamente tramite JSON (JavaScript Object Notation).

 

Vantaggi:

• Portabilità dell'interfaccia su altri tipi di piattaforme
• Prestazioni e scalabilità eccellenti
• Sviluppo indipendente dei diversi componenti
• Migrazione su altri server o modifiche al database agevole (sempre nel rispetto dell’invio corretto dei dati da ogni richiesta)
• Flessibilità complessiva dello sviluppo
• Indipendenza dal tipo di sistema operativo, software e piattaforma in uso
• Possibilità di utilizzare server PHP, Java, Python o Node.js

 

API GraphQL

GraphQLsta per Graph Query Language ed è stato originariamente sviluppato da Facebook nel 2012 per uso interno. Nel 2015, Facebook ha rilasciato GraphQL come open source e da allora GraphQL è stato consegnato alla GraphQL Foundation, fondata appositamente per questo scopo e a sua volta supportata dalla Linux Foundation. GraphQL è una miscela di un ambiente di runtime che include librerie per diversi linguaggi di programmazione come Python, PHP, Ruby o JavaScript e un database con sintassi simile a SQL. La validità delle interrogazioni viene interrogata tramite il sistema di tipizzazione, che può identificare e autenticare l'utente con l'aiuto di voci speciali e di una struttura individuale.
La caratteristica unica di GraphQL è che il Client può specificare quali dati desidera: il server presenta una selezione di dati che possono essere interrogati e il Client decide esattamente quali dati desidera. Questo rende il tutto molto più efficiente perché non vengono trasferiti dati inutili, ma solo quelli di cui il Client ha effettivamente bisogno. 

 

Vantaggi:

• Interoperabilità tra diverse tecnologie
• Personalizzazione flessibile delle API
• Indipendenza da linguaggi di programmazione e dalle infrastrutture IT
• Scambio diretto di informazioni in formato database
• Il linguaggio di query è standardizzato
• Tipizzazione statica
• Facile integrazione nel proprio codice con l'aiuto delle librerie
• L'ambiente di runtime completo è disponibile in formato open source

 

REST vs GRAPHQL

 

Graphql offre un certo multiplexing per le chiamate API e questa è la prima differenza con REST. In REST abbiamo molti singoli Endpoint che definiscono una risorsa così come la sua identità e, nel caso più semplice, abbiamo 4 modi per accedere a questa risorsa. In GraphQL, invece, c'è un solo Endpoint, che di solito si chiama /GraphQL, e tutte le query possono essere eseguite attraverso questo Endpoint; le Mutations e l'Endpoint non sono equiparati a una risorsa o a un'identità, che in GraphQL sono deliberatamente separati l'uno dall'altro. Queste premesse non sono tuttavia ancora sufficienti per declamare un vero vincitore perché il tutto ha i suoi vantaggi e svantaggi.

A differenza di REST con GraphQL non c’è né over-fetching né under-fetching. Un altro problema presente in REST ma non in GraphQL è quello delle richieste n+1 (n+1 request problem). Se ho un elenco di elementi e poi vorrei avere alcuni dettagli dei singoli elementi questo può essere espresso efficacemente in una singola query con GraphQL. Un altro aspetto che parla a favore di GraphQL è la type safety che è direttamente integrata nello schema per impostazione predefinita. Con REST posso provare a fornire questo tramite API aperte specificando uno schema JSON, ma questa è solo un'estensione che non è disponibile con tutte le API. Se la descrizione che ottengo tramite API aperta corrisponde effettivamente all'API reale è sempre più una questione di fortuna che di garanzia e GraphQL in tutto ciò è molto più rigoroso perché è tipizzato e standardizzato. 

Con tutti questi punti a favore di GraphQL rimane qualche aspetto a favore di REST? Sì.

Il vantaggio di GraphQL di avere solo un Endpoint è allo stesso tempo anche uno svantaggio perché non posso eseguire il caching in quanto un solo Endpoint può essere usato in numerosi modi diversi. Il protocollo HTTP implementa una richiesta di caching standard. Anche l’assenza di over e under-fetching ha uno svantaggio. È possibile che se si specifica una selezione molto grande il server abbia bisogno di molti Resolver. Ciò significa che possono essere eseguite molte query sul database o sulle API sottostanti e poi il tutto deve essere aggregato, il che può rivelarsi molto costoso.
Anche la tipizzazione statica di GraphQL è molto rigida. Nel momento in cui voglio ospitare dati dinamici, diventa molto difficile esprimerli in GraphQL ed è qui che GraphQL, con la sua tipizzazione, si scontra con i suoi limiti, perché è un sistema di tipi statici su cui tutto deve girare.
La distinzione fondamentale in entrambi i casi: GraphQL è più funzionale, REST è più tecnico e non si può dire che uno sia giusto e l'altro sbagliato. Si tratta piuttosto di decidere, a seconda della situazione, se è utile un'API basata su GraphQL o se è utile un'API basata su REST e potrebbe essere sensato utilizzarle entrambe in un progetto, approfittando della tipizzazione statica di GraphQL e della dinamicità di REST. 

 

Conclusione

 

Si tende sempre a creare frizione tra tecnologie cercando sempre un vincitore, oggi ad esempio, molti programmatori sono orientati all’utilizzo di GraphQL, mentre dieci anni fa, quando REST sostituì SOAP, la storia era inversa. 

Il problema di queste posizioni è che auto selezionano unilateralmente una tecnologia invece di considerare come le sue effettive caratteristiche e peculiarità si adattino meglio alla situazione in questione o come farlo integrando più tecnologie contemporaneamente valutando bene caso per caso che è quello che facciamo a DevInterface.

Interessato a metterti in contatto con noi? Puoi farlo scrivendoci contattandoci.