API REST e GraphQL: qual è la differenza?

In quanto canali attraverso i quali i componenti software interagiscono e i dati fluiscono su Internet, le API sono la linfa vitale dei servizi web contemporanei. Le tecnologie API come SOAP (un protocollo di messaggistica per servizi web), REST (uno stile architettonico) e GraphQL (un linguaggio e uno strumento di programmazione) semplificano lo sviluppo del software consentendo l'integrazione di dati e servizi di terze parti. Le API consentono inoltre alle aziende di offrire funzioni di servizio sicure e lo scambio di dati a dipendenti, business partner e utenti.

Nonostante i numerosi tipi di API, negli ultimi anni il dibattito è stato dominato da due paradigmi principali: REST (representational state transfer) e GraphQL. Entrambi offrono una serie di benefici e per questo motivo vengono utilizzati per progetti di networking in tutto il mondo. Tuttavia, differiscono notevolmente nel modo in cui gestiscono il traffico dati. In questo articolo analizzeremo queste differenze e discuteremo di come le aziende possono utilizzare le API REST e GraphQL per ottimizzare le proprie reti.

La comprensione delle API REST e GraphQL singolarmente è necessaria per un confronto tra le due.

REST

Sviluppato nei primi anni 2000, REST è uno stile architettonico strutturato per applicazioni ipermediali in rete, progettato per utilizzare un protocollo di comunicazione client/server senza stato e memorizzabile nella cache. Le API REST, chiamate anche API RESTful, sono i driver delle architetture REST.

Le API REST utilizzano identificatori di risorse univoci (URI) per indirizzare le risorse. Le API REST funzionano facendo in modo che diversi endpoint eseguano operazioni CRUD ("create", "read", "update" e "delete") per le risorse di rete. Si affidano a un formato dati predefinito, chiamato tipo di media o tipo MIME, per determinare la forma e la dimensione delle risorse che forniscono ai client. I formati più comuni sono JSON e XML (e talvolta HTML o testo normale).

Quando il client richiede una risorsa, il server elabora la query e restituisce tutti i dati associati a tale risorsa. La risposta include codici di risposta HTTP come "200 OK" (per richieste REST riuscite) e "404 Not Found" (per risorse che non esistono).

graphql

GraphQL è un linguaggio di query e un runtime API che Facebook ha sviluppato internamente nel 2012 prima di diventare open source nel 2015.

GraphQL è definito dallo schema API scritto nel linguaggio di definizione dello schema GraphQL. Ogni schema specifica i tipi di dati che l'utente può interrogare o modificare e le relazioni tra i tipi. Un resolver supporta ogni campo in uno schema. Il resolver fornisce istruzioni per trasformare le query, le mutazioni e le sottoscrizioni di GraphQL in dati e recupera i dati da database, cloud service e altre fonti. I resolver forniscono anche specifiche di formattazione dei dati e consentono al sistema di unire i dati da varie fonti.

A differenza di REST, che in genere utilizza più endpoint per recuperare dati ed eseguire operazioni di rete, GraphQL espone i modelli di dati utilizzando un singolo endpoint attraverso il quale i client inviano richieste GraphQL, indipendentemente da ciò che stanno chiedendo. L'API accede quindi alle proprietà delle risorse e segue i riferimenti tra le risorse per fornire al client tutti i dati di cui ha bisogno da una singola query al server GraphQL.

Sia le API GraphQL che le API REST sono interscambi di dati basati su risorse che utilizzano metodi HTTP (come le richieste PUT e GET) che determinano quali operazioni un client può eseguire. Tuttavia, tra loro esistono differenze fondamentali che spiegano non solo la proliferazione di GraphQL, ma anche perché i sistemi RESTful hanno una tale resistenza.

GraphQL offre un'aggiunta efficiente e più flessibile a REST; le API GraphQL sono spesso viste come un aggiornamento rispetto agli ambienti RESTful, soprattutto data la loro capacità di facilitare la collaborazione tra i team front-end e back-end. GraphQL fornisce un logico passo successivo nel percorso verso le API di un'organizzazione, aiutando a risolvere i problemi che si riscontrano spesso con REST.

Tuttavia, REST è stato a lungo lo standard per le architetture API e molti sviluppatori e architetti si affidano ancora alle configurazioni RESTful per gestire le loro reti IT. Pertanto, la comprensione delle distinzioni tra i due è parte integrante della strategia di gestione IT di qualsiasi organizzazione.

Le API REST e GraphQL differiscono nel modo in cui gestiscono:

Recupero dati

Poiché REST si basa su più endpoint e interazioni stateless, in cui ogni richiesta API viene elaborata come una nuova query, indipendentemente dalle altre, i client ricevono tutti i dati associati a una risorsa. Se un client necessita solo di un sottoinsieme di dati, riceve comunque tutti i dati (over-fetching). E se il client ha bisogno di dati che si estendono su più risorse, un sistema RESTful spesso fa in modo che il client interroghi ogni risorsa separatamente per compensare il recupero inadeguato dei dati dalla richiesta iniziale (under-fetching). Le API GraphQL utilizzano un singolo endpoint GraphQL per fornire ai client una risposta precisa e completa ai dati in un unico viaggio da una singola richiesta, eliminando i problemi di recupero eccessivo e insufficiente.

Controllo delle versioni

In un'architettura REST, le squadre devono eseguire la versione delle API per modificare le strutture dei dati e prevenire errori di sistema e interruzioni del servizio per l'utente finale. In altre parole, gli sviluppatori devono creare un nuovo endpoint ogni volta che apportano modifiche, generando più versioni API e potenzialmente complicando la manutenzione. GraphQL riduce la necessità di controllare le versioni perché i client possono specificare i propri requisiti di dati nella query. L'aggiunta di nuovi campi al server non influisce sui client che non necessitano di tali campi. Al contrario, se i campi sono obsoleti, i client possono continuare a richiederli fino a quando non vengono aggiornate le query.

Gestione degli errori

Le API REST devono utilizzare i codici di stato HTTP per indicare lo stato o il successo di una richiesta e ogni codice di stato ha un significato specifico. Una richiesta HTTP riuscita restituisce un codice di stato 200, mentre un errore del client potrebbe restituire un codice di stato 400 e un errore del server potrebbe restituire un codice di stato 500.

A prima vista, questo approccio alla segnalazione dello stato sembra più semplice, ma i codici di stato HTTP sono spesso più utili per gli utenti web che per le API stesse, soprattutto in caso di errori. REST non dispone di una specifica per gli errori, quindi gli errori API possono apparire come errori di trasporto o non apparire affatto con il codice di stato. Questa dinamica può costringere il personale a leggere la documentazione di stato per capire cosa significano gli errori o anche come gli errori vengono comunicati all'interno dell'infrastruttura.

Con le API GraphQL, ogni richiesta, indipendentemente dal fatto che abbia generato un errore, restituisce un codice di stato 200 OK perché gli errori non vengono comunicati utilizzando i codici di stato HTTP (ad eccezione degli errori di trasporto). Al contrario, il sistema comunica gli errori nel corpo della risposta insieme ai dati, quindi i client devono analizzare il payload dei dati per determinare se la richiesta ha avuto esito positivo.

Detto questo, GraphQL ha una specifica per gli errori, quindi gli errori API sono più facilmente distinguibili dagli errori di trasporto. L'esatta natura degli errori appare nella voce "errors" nel corpo della risposta, il che può rendere preferibile l'utilizzo delle API GraphQL.

Dati in tempo reale

REST non dispone del supporto integrato per gli aggiornamenti in tempo reale. Se un'app ha bisogno di funzionalità in tempo reale, gli sviluppatori devono solitamente implementare tecniche come il long-polling (in cui il client esegue ripetutamente il polling del server per ottenere nuovi dati) e gli eventi inviati dal server, il che può aumentare la complessità dell'applicazione.

Tuttavia, GraphQL include il supporto integrato per gli aggiornamenti in tempo reale attraverso le sottoscrizioni. Gli abbonamenti mantengono una connessione stabile al server, permettendo al server di inviare aggiornamenti al client ogni volta che si verificano eventi specifici.

Strumenti e ambiente

L'ambiente REST è ben consolidato, con un'ampia gamma di strumenti, librerie e framework a disposizione degli sviluppatori. Lavorare con le API REST richiede comunque ai team di navigare tra diversi endpoint e di comprendere le convenzioni e i modelli unici di ciascuna API.

Le API GraphQL sono relativamente nuove, ma l'ambiente GraphQL è cresciuto notevolmente dalla sua introduzione, con vari strumenti e librerie disponibili sia per lo sviluppo del server che del client. Strumenti come GraphiQL e GraphQL Playground offrono potenti ambienti di sviluppo integrati nel browser (IDE) per esplorare e testare le API GraphQL. Inoltre, GraphQL ha un forte supporto per la generazione di codice, che può semplificare lo sviluppo lato client.

Memorizzazione nella cache

Le API REST si basano su meccanismi come eTag e intestazioni dell'ultima modifica per mettere in cache le chiamate API. Sebbene efficaci, queste strategie di memorizzazione nella cache possono risultare complesse da implementare e potrebbero non essere adatte a tutti i casi d'uso.

Le API GraphQL possono essere più difficili da memorizzare nella cache a causa della natura dinamica delle query. Tuttavia, l'implementazione di query persistenti, la memorizzazione nella cache delle risposte e la memorizzazione nella cache lato server possono mitigare queste sfide e ottimizzare gli sforzi di memorizzazione nella cache più ampi nelle architetture GraphQL.

Né le API REST, né le API GraphQL sono intrinsecamente superiori; sono strumenti diversi, adatti a compiti diversi.

REST è generalmente più facile da implementare e può essere una buona scelta quando si preferisce un protocollo di comunicazione semplice e memorizzabile nella cache con rigorosi controlli di accesso (per siti di e-commerce rivolti al pubblico come Shopify e GitHub, ad esempio). Considerati i rischi di under-fetching e over-fetching, le API REST sono più adatte per:

• Aziende che utilizzano app più piccole con profili dati più semplici
• Aziende senza requisiti complessi di query di dati
• Aziende in cui la maggior parte della clientela utilizza dati e operazioni in modi simili

Le API GraphQL consentono un recupero dei dati più flessibile ed efficiente, che può migliorare le prestazioni del sistema e la facilità d'uso per gli sviluppatori. Queste funzioni rendono GraphQL particolarmente utile per la creazione di API in ambienti complessi con requisiti front-end in rapida evoluzione. Questo include:

• Aziende con larghezza di banda limitata che desiderano limitare chiamate e risposte
• Aziende che desiderano combinare i punti dati in un unico endpoint
• Aziende le cui richieste dei clienti variano in modo significativo

Sebbene utilizzino approcci diversi, sia le API GraphQL che REST hanno il potenziale per migliorare notevolmente la scalabilità della rete e le prestazioni del server.

Indipendentemente dal fatto che tu scelga di implementare API REST o GraphQL, o una combinazione delle due, la tua azienda può trarre beneficio da un'ampia gamma di potenziali applicazioni, tra cui implementazioni in vari linguaggi di programmazione (come JavaScript) e integrazione con microservizi e architetture serverless. Con IBM API Connect, è possibile utilizzare entrambi i tipi di API per ottimizzare l'infrastruttura IT.

IBM API Connect è una soluzione di gestione delle API che ti aiuta a creare, gestire, proteggere, socializzare e monetizzare le API, promuovendo la trasformazione digitale nei data center e negli ambienti cloud. Questo significa che sia le imprese che i clienti possono potenziare le app digitali e stimolare l'innovazione in tempo reale.

Con API Connect, le aziende possono contribuire a garantire di operare all'avanguardia nella gestione delle API, il che si rivelerà prezioso in un landscape informatico destinato a diventare più ampio, complesso e competitivo nel tempo.