Ciao, e benvenuto nella nona puntata della quarantatreesima stagione. Nelle scorse puntate ho raccontato REST con ammirazione, e lo merita. Ma oggi, come sempre verso la fine, mettiamo sul tavolo la verità onesta: REST non è perfetto, e non è l'unica via. Ha dei limiti reali, e per certi problemi ci sono alternative migliori. Conoscerli non serve a bocciare REST, che resta ottimo per moltissimi casi: serve a scegliere con la testa, invece che per abitudine. Oggi vediamo i limiti di REST, e le sue alternative.
Partiamo da una precisazione onesta, perché sgombra il campo. Nella pratica, REST è più libero della teoria. È uno stile, un insieme di idee e convenzioni, non uno standard rigido che tutti seguono in modo identico. Quasi tutte le API vere prendono le parti utili di REST, le risorse, i pochi verbi, i codici di stato, il formato di testo condiviso, e tralasciano le parti più puriste. E va benissimo così: l'importante è prendere il valore delle idee, non seguire un dogma. Diffida di chi ti dice che una cosa non è vero REST: quasi nulla lo è al cento per cento, e non è un problema.
Voglio ora affrontare il limite più concreto, perché lo vivrai davvero. Il difetto pratico più noto di REST nasce da un'idea che abbiamo lodato: ogni risorsa ha la sua fotografia, con un contenuto abbastanza fisso. Il problema è che spesso quella fotografia ti dà troppo, oppure troppo poco. Troppo: ricevi un mucchio di campi che non ti servivano, sprecando dati e tempo, soprattutto su un telefono con una rete lenta. Troppo poco: per comporre una sola schermata ti servono cose che stanno in fotografie diverse, e allora devi fare tante richieste separate, una dopo l'altra, per raccogliere tutti i pezzi. Troppi dati per volta, o troppi viaggi: è il prezzo di avere fotografie a taglia fissa.
Voglio presentarti la prima alternativa, perché risolve proprio questo. Per rispondere a questo problema è nato uno stile diverso, chiamato GraphQL. La sua idea: invece di darti fotografie a taglia fissa, lascia che sia il cliente a chiedere esattamente i campi che vuole, né più né meno, in una sola richiesta. Vuoi solo il nome e l'ultimo ordine di un utente? Li chiedi, e ricevi solo quelli, in un colpo solo. Risolve elegantemente sia il troppo che il troppo poco. Il prezzo? Sposta la complessità sul servizio, che deve saper comporre al volo qualunque richiesta, ed è più difficile da mettere in cache, cioè da tenere in memoria di scorta, come vedemmo con Redis. Nessun pasto gratis: risolvi un problema, ne accetti un altro.
Voglio presentarti la seconda alternativa, perché copre un altro bisogno. Poi c'è un altro stile ancora, chiamato gRPC, pensato per un caso diverso: la comunicazione velocissima tra servizi interni, quando due programmi che controlli tu devono parlarsi tantissimo e in fretta. Rinuncia alla leggibilità umana, quel testo che un occhio umano capisce, in cambio di pura efficienza: messaggi più compatti e veloci, ottimi tra macchine, ma non fatti per essere letti da noi né aperti facilmente in un browser. È lo strumento giusto quando la priorità assoluta è la velocità nel dialogo fitto tra servizi.
Voglio darti la bussola per scegliere, perché è la lezione di sempre. E qui torna la verità che questo podcast ripete da tante stagioni: non esiste lo strumento migliore in assoluto, esiste quello giusto per la forma del tuo problema. REST brilla per le API pubbliche, per la vastità di chi lo capisce, per la semplicità, per la facilità di tenerne in cache le risposte, per l'uso del web così com'è: ed è per questo che resta, di gran lunga, la scelta più comune. GraphQL brilla quando il cliente ha bisogni di dati complessi e variabili. Il terzo brilla nel dialogo interno ad altissima velocità. Spesso, nei sistemi veri, convivono tutti e tre, ciascuno dove rende meglio. La saggezza non è tifare per uno, ma saper riconoscere quale forma ha il tuo problema.
Voglio chiudere con una nota rassicurante, perché tocca un filo caro. Su un punto REST, e il web su cui poggia, sono tranquillizzanti. REST è costruito su standard aperti del web, che non appartengono a nessuno: nessuna azienda li possiede, nessuno può revocarteli o cambiarti le regole da un giorno all'altro. Quella apertura è parte del perché REST è ovunque e ci si può costruire sopra senza timori. Sulla domanda che ci accompagna, chi possiede le tue opzioni, qui la risposta è serena: le possiede il web stesso, un bene comune di tutti. Scegliere REST significa anche appoggiarsi su fondamenta che nessuno ti può togliere.
Per oggi ci fermiamo qui. La verità onesta: REST non è perfetto, ed è più uno stile libero che uno standard rigido, e va bene così. Il suo limite pratico più noto è dare troppo o troppo poco: campi che non servono, o tante richieste per comporre una schermata. A questo rispondono altre vie: uno stile in cui è il cliente a chiedere esattamente i campi che vuole, e un altro ottimizzato per il dialogo velocissimo tra servizi, ciascuno con i suoi compromessi. La bussola è la solita: nessuno strumento è il migliore in assoluto, conta la forma del problema, e spesso convivono. Con la nota serena che REST poggia su standard aperti di tutti, che nessuno ti può togliere. Nella prossima e ultima puntata tiriamo le somme, e vediamo il tessuto connettivo del web. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.