Ciao, e benvenuto nella seconda puntata della quarantatreesima stagione. Nella scorsa puntata abbiamo capito cos'è un'API: uno sportello, un menù di richieste che un servizio offre agli altri programmi. Oggi entriamo nel cuore di REST, nell'idea che lo definisce più di ogni altra: tutto è una risorsa. È un modo di pensare, prima ancora che una tecnica. E una volta che lo afferri, capisci l'ossatura di quasi tutte le API del web.
Partiamo dal modo ingenuo di organizzare un'API, perché è quello da cui si scappa. Immagina di dover costruire il menù del tuo servizio. Il modo istintivo è pensare alle azioni, ai comandi: prendimi un utente, crea un ordine, cancella una foto, aggiorna un indirizzo, calcola un totale, e così via. Fai una lista di verbi, di operazioni. Il problema? Questa lista non finisce mai. Ogni nuova esigenza aggiunge un nuovo comando, con un nome inventato lì per lì, diverso da servizio a servizio. Il menù cresce in modo disordinato, imprevedibile, e chi vuole usarlo deve imparare a memoria un elenco caotico di comandi, tutti diversi. È un pantano.
Voglio darti il ribaltamento di REST, perché è tutta qui la sua eleganza. REST capovolge la prospettiva. Dice: non organizzare l'API attorno alle azioni, ma attorno alle cose. Invece di pensare ai verbi, pensa ai sostantivi. Queste cose si chiamano risorse. Una risorsa è qualunque cosa il tuo servizio conosca e gestisca: un utente è una risorsa, un ordine è una risorsa, un prodotto, una foto, un commento. Il centro dell'API non sono più le azioni che puoi fare, ma le cose su cui puoi agire. Pensi per nomi di cose, non per elenchi di comandi.
Voglio farti apprezzare perché questo cambi tutto, perché è profondo. Ecco il punto: i sostantivi sono stabili e numerabili, i verbi sono infiniti e caotici. Un servizio ha un insieme conoscibile di cose: ha utenti, ordini, prodotti, e poche altre. È un elenco finito, che puoi disegnare e capire. Le azioni, invece, sono senza fine: puoi sempre immaginare una nuova operazione da fare su qualcosa. Centrando l'API sulle cose, che sono poche e stabili, l'interfaccia diventa ordinata, prevedibile, esplorabile. Chi la guarda capisce subito di cosa tratta il servizio: bastano i nomi delle sue risorse a raccontarlo. È come conoscere una città dai suoi quartieri, invece che da un elenco infinito di cose che ci puoi fare.
Voglio darti l'immagine che rende chiara questa idea, perché è quotidiana. Pensa a una biblioteca. Un modo pessimo di organizzarla sarebbe per attività: uno scaffale per portami-un-giallo, uno per rimetti-a-posto-il-libro-rosso, uno per cerca-qualcosa-di-avventura. Un caos di azioni. Il modo giusto è organizzarla per cose: i libri, ciascuno al suo posto, con la sua collocazione. Le attività, poi, si fanno sui libri: prendere, restituire, cercare, si applicano tutte alle stesse cose, i libri. Le risorse di REST sono i libri della biblioteca: le cose stabili attorno a cui tutto si organizza, mentre le azioni, come vedremo, sono poche e universali.
Voglio anticiparti come questo prepari il resto, perché è un ingranaggio di un meccanismo più grande. Questa scelta, pensare per cose, apre la strada a tutto il resto di REST, che vedremo nelle prossime puntate. Se il centro sono le cose, allora ogni cosa avrà bisogno di un indirizzo per essere raggiunta: e sarà la prossima puntata. E le azioni su quelle cose potranno essere pochissime e sempre le stesse, applicate a tutte: e sarà la puntata dopo ancora. Tutto il resto della bellezza di REST discende da questa prima scelta: mettere le cose, e non le azioni, al centro. È la fondazione su cui poggia l'intero edificio.
Voglio trarre la lezione generale, perché vale ben oltre REST. C'è un principio profondo qui, che ritrovi in tutta la buona progettazione: modellare un sistema attorno alle sue cose, ai suoi sostantivi, invece che attorno alle sue azioni, è spesso una scelta più pulita e potente. Le cose ti danno una struttura stabile su cui poggiare; le azioni, da sole, danno solo una lista che cresce all'infinito. Chiediti sempre, di fronte a un problema: quali sono le cose in gioco? Nominarle bene, e organizzare tutto attorno a loro, è metà del lavoro fatto. È un'abitudine mentale che rende ordinati non solo le API, ma quasi tutti i sistemi che costruirai.
Per oggi ci fermiamo qui. Siamo entrati nel cuore di REST: tutto è una risorsa. Il modo ingenuo di fare un'API è per azioni, per comandi, una lista che cresce all'infinito e diversa ovunque. REST ribalta tutto: organizza attorno alle cose, alle risorse, i sostantivi, non i verbi. E i sostantivi sono stabili e numerabili, mentre i verbi sono infiniti: per questo un'API centrata sulle cose è ordinata e prevedibile, come una biblioteca organizzata per libri e non per attività. Da questa scelta discende tutto il resto di REST. La lezione: modellare un sistema attorno alle sue cose, non alle sue azioni, è una delle abitudini più potenti del buon progettare. Nella prossima puntata vediamo come si dà un indirizzo a ogni risorsa. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.