Questi due metodi di costruzione delle API sono completamente diversi. In pratica, queste tecnologie funzionano inviando una richiesta HTTP e ricevendo il risultato. Entrambe hanno i loro pro e contro e in questo articolo parleremo diffusamente di queste due grandi tecnologie che hanno cambiato il modo di sviluppare e scalare le API.<\/p>\n
Prima di addentrarci nei dettagli, per\u00f2, esploriamo il significato di GraphQL e API RESTful.<\/p>\n
Cos’\u00c8 GraphQL?<\/h2>\n
GraphQL \u00e8 un linguaggio di interrogazione delle API<\/a> e un runtime per rispondere a tali interrogazioni con i dati esistenti. Inoltre \u00e8 dotato di potenti strumenti per gestire anche le query pi\u00f9 complesse.<\/p>\n La caratteristica principale di GraphQL \u00e8 la capacit\u00e0 di richiedere e ricevere solo<\/em> i dati specifici richiesti, niente di pi\u00f9. Questo rende molto pi\u00f9 semplice scalare le vostre API insieme alla vostra applicazione.<\/p>\n L’aspetto pi\u00f9 interessante di GraphQL \u00e8 la sua capacit\u00e0 di fornire tutti i dati in un unico endpoint.<\/p>\n Il diagramma qui sopra \u00e8 una tipica rappresentazione dell’architettura GraphQL. I clienti fanno richieste da diversi dispositivi e GraphQL gestisce le loro richieste e restituisce solo i dati richiesti. In questo modo si risolve il problema dell’over-fetching e dell’under-fetching delle API RESTful.<\/p>\n Nell’esempio qui sopra, mostriamo un ambiente GraphQL e il modo in cui potete interrogare i dati con un singolo endpoint. In alto c’\u00e8 l’endpoint dell’API, a sinistra la query che richiede i nomi dei continenti e infine, a destra, la risposta alla query richiesta.<\/p>\n GraphQL \u00e8 stato creato da Facebook con lo scopo principale di risolvere l’esperienza di chi sviluppa applicazioni<\/a> mobili che lavorano con le API REST. Da quando \u00e8 stata rilasciata la prima versione open-source nel 2015, GraphQL ha registrato una crescita enorme grazie all’adozione della tecnologia da parte di grandi aziende del settore tecnologico.<\/p>\n Di seguito elenchiamo solo alcune delle aziende e delle applicazioni che usano GraphQL attivamente sui loro server.<\/p>\n Facebook ha creato GraphQL e lo utilizza in produzione per le sue applicazioni mobili dal 2012. L’azienda multimiliardaria di social network ha reso pubbliche le specifiche di GraphQL nel 2015, rendendole accessibili in molti ambienti e a team di ogni dimensione.<\/p>\n Anche GitHub<\/a> ha dichiarato di usare GraphQL fornendo un’API GraphQL per creare integrazioni, recuperare dati e automatizzare i flussi di lavoro tramite l’API GraphQL di GitHub. L’API GraphQL di GitHub offre query pi\u00f9 precise e flessibili rispetto all’API REST di GitHub.<\/p>\n Anche Pinterest \u00e8 uno dei primi utilizzatori di GraphQL. Il gigante della condivisione di foto ha discusso pubblicamente<\/a> la sua esplorazione iniziale di GraphQL e il modo in cui usa la tecnologia GraphQL che alimenta la sua azienda da un miliardo di dollari.<\/p>\n Molte altre aziende miliardarie<\/a> come Intuit, Shopify<\/a>, Coursera e Airbnb alimentano le loro applicazioni con GraphQL. E questa ampia preferenza per REST non fa che crescere.<\/p>\n REST \u00e8 l’acronimo di “Representational State Transfer”, uno stile architettonico per sistemi ipermediali distribuiti. Definisce principi e vincoli per lo scambio di risorse tra il server e i client.<\/p>\n Se questi principi vengono seguiti in un’API, l’applicazione di quell’API viene definita “RESTful”. L\u2019API REST di WordPress<\/a> ne \u00e8 un esempio lampante.<\/p>\n Di seguito sono elencati alcuni dei principi e dei vincoli che un’API deve soddisfare per essere definita API Restful:<\/p>\n Il diagramma sottostante rappresenta l’architettura REST di base. Mostra come vengono gestite le richieste e le risposte.<\/p>\n Vi elenchiamo alcuni vantaggi dell’uso di GraphQL, che illustrano perch\u00e9 \u00e8 pi\u00f9 che sufficiente per costruire la prossima app da un miliardo di dollari.<\/p>\n Il vantaggio principale di GraphQL \u00e8 la possibilit\u00e0 di accedere a tutti i dati attraverso un unico endpoint API<\/a>.<\/p>\n Uno dei problemi pi\u00f9 comuni delle API RESTful \u00e8 quello di avere troppi endpoint per accedere alle informazioni. Con GraphQL, invece, avete un solo endpoint, quindi non dovete inviare pi\u00f9 richieste per recuperare diverse informazioni su un oggetto.<\/p>\n Il diagramma sottostante mostra un chiaro esempio di recupero di risorse tramite API RESTful e GraphQL. Potete vedere che c’\u00e8 un solo endpoint per accedere alla risorsa nel server GraphQL, mentre sono necessari pi\u00f9 endpoint API per accedere a diverse risorse nell’API RESTful.<\/p>\n Il problema dell’over-fetching o dell’under-fetching \u00e8 un problema noto delle API RESTful. Ci\u00f2 accade quando i clienti scaricano i dati colpendo endpoint che restituiscono strutture di dati fisse, oppure recuperano pi\u00f9 o meno di quanto previsto.<\/p>\n L’over-fetching fa s\u00ec che la richiesta riceva – o “recuperi” – pi\u00f9 dati di quelli richiesti da una determinata richiesta. Immaginate di recuperare tutti gli utenti di una tabella con l’intenzione di visualizzare i loro nomi nella vostra homepage. In questo caso, l’over-fetching restituir\u00e0 tutti<\/em> i dati di ogni utente, compreso (ma non solo) il nome.<\/p>\n L’under-fetching \u00e8 relativamente raro, ma si verifica quando l’endpoint specifico non riesce a fornire tutte le informazioni richieste. Il cliente dovr\u00e0 effettuare ulteriori richieste per accedere alle altre informazioni necessarie.<\/p>\n GraphQL risolve in modo efficiente il problema dell’over-fetching o dell’under-fetching, recuperando l’esatta risorsa richiesta dal cliente senza alcun dettaglio aggiuntivo.<\/p>\n GraphQL pu\u00f2 unificare e nascondere la complessit\u00e0 di sistemi multipli integrati.<\/p>\n Per esempio, supponiamo di voler migrare da un’applicazione backend monolitica a un’architettura a microservizi<\/a>. L’API GraphQL aiuta a gestire la comunicazione tra vari microservizi unendoli in un unico schema GraphQL.<\/p>\n Una volta definiti questi schemi, sia il frontend che il backend possono comunicare separatamente senza ulteriori modifiche, poich\u00e9 il frontend sa che i dati dello schema saranno sempre sincronizzati in tutto il sistema.<\/p>\n Il problema dell’over-fetching pu\u00f2 comportare un maggiore consumo di banda per i client che, a lungo andare, pu\u00f2 causare rallentamenti nell’applicazione. L’utilizzo di modelli di progettazione delle API RESTful richiede pi\u00f9 tempo per selezionare le informazioni necessarie da un carico enorme.<\/p>\n Grazie alla capacit\u00e0 di GraphQL di evitare l’over fetching e l’under fetching, il server restituisce una forma sicura, facile da leggere e prevedibile che rende le richieste e le risposte dell’API pi\u00f9 veloci.<\/p>\n Nonostante la crescente popolarit\u00e0 di GraphQL, REST \u00e8 ancora uno degli standard API pi\u00f9 diffusi. Vediamo perch\u00e9.<\/p>\n Ora che abbiamo discusso i pro di GraphQL rispetto a REST, analizziamo alcuni degli svantaggi di GraphQL:<\/p>\n Ora, rivolgiamo la nostra attenzione ad alcuni degli svantaggi di REST:<\/p>\n A seguire, parleremo dei motivi per cui potreste prendere in considerazione GraphQL per il vostro futuro sviluppo di API invece di API RESTful.<\/p>\n GraphQL usa un sistema di tipi forti per definire le funzionalit\u00e0 dell’API. In GraphQL, il linguaggio di definizione dello schema (SDL) si usa per definire i parametri relativi alle modalit\u00e0 di accesso del client ai dati del server. Tutte le API esposte al cliente sono scritte in SDL, risolvendo il problema dell’incoerenza dei dati che si riscontra nelle API RESTful.<\/p>\n Il problema dell’over-fetching o dell’under-fetching \u00e8 un problema noto delle API RESTful, in cui i clienti ricevono pi\u00f9 o meno informazioni di quelle richieste. GraphQL risolve questo problema fornendo al cliente un mezzo per specificare le informazioni necessarie e restituendo esattamente – e solo<\/em> – quelle informazioni specifiche.<\/p>\n Uno dei maggiori problemi delle API RESTful \u00e8 quello di avere troppi endpoint per accedere alle informazioni.<\/p>\n Supponiamo che vogliate accedere a un particolare utente tramite il suo numero ID. Vi verrebbe presentato un endpoint come Con GraphQL, invece, avete un unico endpoint e non dovete inviare pi\u00f9 richieste per recuperare diverse informazioni sull’utente.<\/p>\n Infine, analizzeremo le principali differenze tra GraphQL e le API RESTful. In seguito discuteremo alcune delle caratteristiche di un buon design di API e confronteremo il modo in cui ciascuna tecnologia le gestisce.<\/p>\n Non c’\u00e8 dubbio che GraphQL sia pi\u00f9 veloce delle API RESTful grazie alla sua capacit\u00e0 di fornire un unico endpoint per accedere a tutte le risorse. Le API RESTful utilizzano pi\u00f9 endpoint, il che potrebbe comportare una latenza di rete<\/a>.<\/p>\n Poich\u00e9 gli endpoint non sono separati in pi\u00f9 endpoint, le query GraphQL possono diventare sempre pi\u00f9 complesse nel tempo. Gli endpoint delle API RESTful, invece, sono separati e questo limita le API RESTful a query semplici.<\/p>\n GraphQL \u00e8 un modello architettonico di API e un linguaggio di query in crescita. Sebbene sia ancora giovane, il suo tasso di adozione e il suo bacino di risorse stanno crescendo rapidamente e le risorse abbondano gi\u00e0 per chi vuole impararlo in autonomia.<\/p>\n REST, invece, vanta gi\u00e0 un vasto supporto da parte della comunit\u00e0 e continua a essere utilizzato da aziende di ogni tipo, da quelle che costruiscono piccoli microservizi a quelle che creano complesse app social e non solo.<\/p>\n Al momento, la gara di popolarit\u00e0 tra GraphQL e REST \u00e8 un pareggio. Entrambe le tecnologie continuano a essere ampiamente utilizzate e ben supportate dalla comunit\u00e0 di sviluppatori.<\/p>\n La curva di apprendimento di GraphQL \u00e8 ripida. Richiede una buona conoscenza del dominio dello sviluppo di API e dell’ingegneria del software<\/a> in generale. Una persona principiante assoluta avr\u00e0 difficolt\u00e0 a capire GraphQL abbastanza bene da costruire un’applicazione complessa.<\/p>\n Al contrario, REST \u00e8 molto semplice da usare e richiede meno conoscenze di dominio. Le API RESTful sono ben integrate nella maggior parte dei linguaggi di programmazione<\/a> e dei framework pi\u00f9 diffusi<\/a>, il che rende molto semplice il loro apprendimento.<\/p>\n GraphQL \u00e8 una nuova tecnologia che segue le orme dei modelli architettonici delle API RESTful, cos\u00ec come REST \u00e8 stato introdotto per risolvere i problemi dei modelli API SOAP.<\/p>\n GraphQL offre risposte pi\u00f9 rapide, un unico endpoint API per tutte le query e uno schema rigoroso per un accesso coerente ai dati. Questi motivi hanno spinto aziende multimiliardarie a passare a GraphQL, anche in fase iniziale. Tuttavia, nonostante i suoi limiti, il progenitore di GraphQL, REST, continua a mantenere una forte presenza sulla scena.<\/p>\n\n In questa guida abbiamo analizzato tutto ci\u00f2 che dovete sapere sulle API GraphQL e RESTful, compresi i vantaggi e gli svantaggi di ciascuna tecnologia, per aiutarvi a decidere con sicurezza quale preferite. Abbiamo anche discusso i problemi noti delle API RESTful – come l’over-fetching, l’under-fetching e gli endpoint multipli – e come GraphQL tenta di risolvere questi problemi e di aumentare le prestazioni della vostra app.<\/p>\n Ora avete abbastanza informazioni per scegliere se GraphQL o REST \u00e8 adatto al vostro prossimo progetto. Fateci sapere nella sezione commenti cosa costruirete con il vostro vincitore!<\/p>\n","protected":false},"excerpt":{"rendered":" Pu\u00f2 essere difficile scegliere le tecnologie da includere nello stack tecnologico del vostro prossimo progetto. In molti casi, e soprattutto quando si tratta di scegliere tra …<\/p>\n","protected":false},"author":193,"featured_media":60341,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_kinsta_gated_content":false,"_kinsta_gated_content_redirect":"","footnotes":""},"tags":[21446,26055,11138,67],"topic":[25883],"class_list":["post-60188","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","tag-api","tag-graphql","tag-rest","tag-webdev","topic-strumenti-di-sviluppo-web"],"yoast_head":"\n![\"Schermata](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/09\/graphql.png\")
![\"Una](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/09\/graphql_code.png\")
Aziende Che Usano GraphQL<\/h2>\n
Facebook<\/h3>\n
![\"Una](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/09\/facebook_page.png\")
GitHub<\/h3>\n
![\"Una](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/09\/github_page.png\")
Pinterest<\/h3>\n
![\"Una](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/09\/pinterest_page.png\")
Cos’\u00c8 un’API RESTful?<\/h2>\n
\n
![\"Schermata](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/09\/rest.png\")
Vantaggi di GraphQL<\/h2>\n
Recuperare i Dati Attraverso un Singolo Endpoint API<\/h3>\n
![\"Un](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/09\/REST-and-GraphQL.png\")
Nessun Over-Fetching o Under-Fetching<\/h3>\n
Migliore Gestione di Sistemi Complessi e Microservizi<\/h3>\n
Veloce e Sicuro<\/h3>\n
Vantaggi di REST<\/h2>\n
\n
Svantaggi di GraphQL<\/h2>\n
\n
Gli Svantaggi di REST<\/h2>\n
\n
Perch\u00e9 Usare GraphQL Invece di REST?<\/h2>\n
Schema Fortemente Tipizzato<\/h3>\n
Nessun Over-Fetching o Under-Fetching<\/h3>\n
Endpoint Multipli<\/h3>\n
\/users\/1<\/code>. Ma se volete accedere alle foto di quell’utente, dovrete inviare una richiesta a un altro endpoint, come \/users\/1\/photos<\/code>.<\/p>\nProva di Forza tra GraphQL e REST<\/h2>\n
Prestazioni<\/h3>\n
Complessit\u00e0 delle Query<\/h3>\n
Popolarit\u00e0 e Supporto della Comunit\u00e0<\/h3>\n
Curva di Apprendimento<\/h3>\n
![\"Una](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/09\/showdown.png\")
Riepilogo<\/h2>\n