saverioriotto.it

Che cos'è l'API. Differenza tra REST e GraphQL

Di recente, GraphQL è stato presentato come un'alternativa rivoluzionaria alle API REST, ma come per qualsiasi altra cosa, ha i suoi pro e contro. In alcuni scenari, GraphQL sarà effettivamente una soluzione migliore, ma in altri potresti scoprire che le API REST sono ancora tra quelli più scelti.

Che cos'è l'API. Differenza tra REST e GraphQL

API è l'acronimo di Application Programming Interface. In parole semplici, un'API è un componente software che consente a due applicazioni di comunicare tra loro.

Simile alle interfacce utente le API consentono le interazioni tra una parte e l'altra, ma a differenza di esse non sono visibili agli utenti finali. L'essenza delle API è fungere da strato di comunicazione tra app e database che consente loro di scambiare e manipolare i dati in modo rapido e sicuro. Molto importante per i programmi scritti in linguaggi diversi, quindi possiamo dire che le API aiutano i programmi a superare la "barriera linguistica".

E per te, come per l'utente dell'applicazione, le API consentono di eseguire alcune azioni all'interno di un'applicazione, ma incidono su più applicazioni contemporaneamente e ricevono informazioni da loro quando e dove sono necessarie.
Ciò significa che quando si utilizza un programma, non è necessario abbandonare il programma corrente per utilizzarne un altro. Ad esempio, stai visitando un sito Web di notizie e stai vedendo un blocco con il meteo nell'angolo in alto a destra. Gli sviluppatori di questo sito Web di notizie richiedono i dati meteorologici attuali utilizzando l'API di weather.com e li visualizzano sul sito Web per gli utenti. In questo modo gli utenti possono ottenere informazioni meteo senza dover uscire dal sito Web corrente e visitare weather.com.

Le API forniscono un accesso immediato e sicuro a dati e funzionalità esterne, quindi non è necessario svilupparlo da zero o mantenere. Un altro esempio è gestire i pagamenti online, che è davvero fondamentale per le piattaforme di e-commerce. E invece di creare un nuovo sistema di pagamento online, può essere semplicemente integrato utilizzando le soluzioni API.

Per avere un esempio più chiaro, l'API può essere confrontata con un menu. I menu contengono un elenco di pietanze e, quando qualcuno ne ordina uno, il ristorante esegue alcune azioni e quindi restituisce il piatto ordinato. Le API definiscono un elenco di comandi e, quando un programma ne utilizza uno, l'altro programma esegue alcune azioni e quindi restituisce ciò che è stato richiesto da quel comando (di solito un tipo di dati).

Inoltre, le API riducono la complessità. Quando ordini cibo da un ristorante, molti passaggi complessi come tagliare gli ingredienti, riscaldare con precisione, inscatolare il cibo, ecc. vengono messi insieme per completare il tuo ordine. Immagina quanto sarebbe irritante se dovessi descrivere ogni fase della cottura di un piatto ordinato? Invece, chedi una voce di menu e il resto avviene automaticamente.

Tuttavia, neanche l'esempio con l'ordinazione dei prodotti alimentari è perfetto. Quando effettui tale ordine, ci sono molte varianti che potresti utilizzare per ottenere lo stesso risultato. Ma i programmi non sono flessibili e intelligenti come gli umani, quindi quando un programma sta facendo una richiesta, deve essere formattato in un modo molto specifico.
Ciò significa che le API definiscono non solo l'elenco dei comandi ma anche il formato di tali. E quando qualcuno rilascia un'API per il proprio software, è come se lo dicessero praticamente a tutti: ecco cosa puoi ottenere dalla nostra app, ed ecco esattamente come devi chiedere per ottenerlo.

Oggi l'utilizzo delle API è cresciuto enormemente. La sopravvivenza nell'ampia economia delle API si basa sulla tua capacità di creare API di facile utilizzo che altri sviluppatori possono sfruttare per ottenere dal tuo servizio le informazioni e le risorse di cui hanno bisogno per espandere le proprie.

Questo diffuso utilizzo delle API ha mostrato alcuni aspetti negativi di come sono state costruite e utilizzate, che hanno portato alla generazione di nuove innovazioni come REST e GraphQL.

L'architettura RESTful è stata lanciata nel 2000 e ha offerto un modo semplice per i computer di interagire tra loro. Questa architettura fa uso del protocollo HTTP per la comunicazione tra computer e questa comunicazione è senza stato. Significa che il server non memorizza lo stato sulla sessione client lato server.

Invece nel 2012 Facebook ha creato GraphQL e lo ha annunciato come alternativa a REST.
GraphQL è un linguaggio di query, una specifica e un set di strumenti che opera su un singolo endpoint utilizzando HTTP. Al contrario di REST, dove ogni risorsa può essere identificata dall'URL e recuperata inviando una richiesta GET a quell'URL specifico, lo sviluppo dell'API con GraphQL richiede uno schema per definire le risorse con cui opererà.

Vantaggi del REST

Uno dei principali vantaggi di REST è la scalabilità. L'architettura separa client e server, il che consente di ridimensionare indefinitamente programmi e applicazioni senza troppe difficoltà.
Inoltre, le API REST offrono una notevole flessibilità. Dato che i dati non sono legati a risorse o metodi, REST può gestire diversi tipi di chiamate e restituire diversi formati di dati, il che consente agli sviluppatori di creare API in grado di soddisfare esigenze specifiche pur essendo consapevoli delle esigenze di una base di utenti diversificata.

Vantaggi di GraphQL

Quando modifichi l'interfaccia utente della tua applicazione, c'è una probabilità piuttosto elevata che anche i requisiti dei tuoi dati vengano modificati, vale a dire che dovrai recuperare più o meno dati di prima. GraphQL rende possibili iterazioni di prodotto così rapide sul front-end in quanto consente di apportare modifiche sul lato client senza fare confusione con il server.
E poiché tutto in GraphQL è guidato dallo schema, l'estensione non sarà un problema in quanto il nuovo campo non influirà su quelli esistenti.
Inoltre, con GraphQL, gli sviluppatori hanno la possibilità di ottenere informazioni dettagliate sui dati richiesti sul back-end e su come vengono utilizzati i dati disponibili. Questo è possibile perché ogni cliente specifica quali informazioni esatte ha bisogno. E con questo gli sviluppatori sono in grado di migliorare le prestazioni dell'API, deprecando i campi che i client non utilizzano più.
GraphQL definisce le capacità delle API utilizzando un sistema di tipo forte che sostanzialmente dice al client come è possibile accedere ai dati. Entrambi i team front-end e back-end conoscono la struttura dei dati che, quindi, consente loro di lavorare in modo indipendente.

GraphQL vs. REST

In generale, il fascino di GraphQL deriva da una maggiore efficienza rispetto a REST. I servizi RESTful spesso restituiscono grandi quantità di dati inutilizzabili mescolati con le informazioni necessarie (di solito è il risultato di più query del server). E questo, quindi, aumenta il tempo necessario per restituire tutti i dati richiesti.

Tuttavia, mentre la battaglia tra GraphQL e REST si inclina di solito verso la prima, ci sono alcuni casi in cui l'API REST è una scelta migliore. Ad esempio, i servizi RESTful sono più efficaci in termini di meccanismi di memorizzazione nella cache HTTP, mentre GraphQL non supporta affatto il browser e la memorizzazione nella cache mobile per accelerare le chiamate.
I servizi RESTful semplificano anche il processo di registrazione SQL. Gli sviluppatori ritengono che l'ottimizzazione delle query dei log SQL con REST sia relativamente semplice rispetto all'approccio dinamico di GraphQL.
Inoltre, le API REST possono utilizzare i codici di stato HTTP per rilevare errori e facilitare il processo di monitoraggio delle API, mentre GraphQL rende difficile gestire questi errori e monitorare le API.

Le API GraphQL possono essere una nuova tecnologia innovativa, ma è importante considerare i compromessi prima di prendere tali decisioni architetturali. Per alcune API, ad esempio, API con pochissime entità e relazioni tra entità (come le API di analisi) GraphQL non è l'opzione migliore. Ma al contrario, le applicazioni che contengono molti oggetti di dominio diversi (come l'e-commerce con articoli, ordini, utenti, pagamenti, ecc.) Potrebbero trovare GraphQL più vantaggioso.

In realtà, confrontare GraphQL e REST è come confrontare i database SQL e NoSQL. Potresti avere un'applicazione in cui ha senso modellare entità complesse in un DB SQL mentre ci sono altre app, ad esempio, che hanno solo "messaggi" in cui NoSQL DB sarà una buona scelta.




Commenti
* Obbligatorio