Concludiamo la nostra serie sulla “filosofia” dello stile architetturale REST, completando l‘analisi delle cosiddette “leggi della semplicità”, che ci hanno guidato nella riconsiderazione dei principi alla base dell‘ideazione e realizzazione di web service.

Introduzione

In questo ultimo articolo riprendo le mie riflessioni su semplicità e stile architetturale REST. Come sempre seguiamo il piccolo manuale di John Maeda [3] che parla delle leggi della semplicità. Rimangono quattro leggi: Emozione, Fiducia e Fallimento, e l’Unica che le racchiude tutte.

“La settima legge non è per tutti: ci sarà sempre il modernista duro e puro che rifiuta ogni oggetto che non sia bianco o nero”. Purtroppo rientro in questa categoria. Il mio computer ha una delicata colorazione argentata che ricorda un puro bianco perla quando ci batte sopra il sole la mattina presto. La mia nuova moto è nera anche se quest’anno andava di moda la versione bicolor. I miei vestiti sono in diverse variazioni del blu: qualche hanno fa, per ribellarmi a me stesso, comprai qualche indumento rosso, ma sempre monocromatico. Non mi piacciono gli ornamenti, i lustrini e i fronzoli. Quindi forse sono la persona meno adatta per parlare di emozioni. Invece voglio tentare lo stesso per il solo motivo che non voglio dare ragione ad alcune ex…

C’è emozione nel freddo mondo della programmazione? In molti pensiamo di sì. Non c’è niente di più bello di un file JSON o XML indentato e colorato. Forse sono malato, ma non credo di essere l’unico. La prova sono tutti quegli sviluppatori che mostrano con orgoglio nei loro wiki pezzi di codice formattati e ordinati. Oppure i designer di linguaggi di programmazione che rimangono in estasi di fronte a un costrutto sintattico o a un modo furbo, anche se arcano, di descrivere qualche algoritmo. Conosco tanta gente che di sicuro preferisce gli script bash alla pornografia.

REST rappresenta le risorse in un formato logico e formale, ma comprensibile da un essere umano. Un file JSON indentato con la sintassi colorata dal syntax checker è indubbiamente bello. Suscita più emozioni di uno freddo stream di bit.

Secondo John Maeda, un oggetto semplice potrebbe sembrare freddo. Meglio quando un oggetto suscita delle emozioni anche a scapito della semplicità. Magari lo stream di bit può richiedere meno byte per trasmettere la stessa informazione, ma il file JSON è di sicuro più umano e per questo più bello ed “emozionante”.

“Don’t be evil”, dicono quelli di Google. Non so quanto il motto di un’azienda sia rispettato dall’azienda stessa. Però il semplice motto contiene una verità. Il successo di Google è legato alla fiducia degli utenti per Google e Google deve agire in modo tale da non tradire quella fiducia perche’ altrimenti sentirebbe scricchiolare la basi su cui fonda il proprio successo.

La semplicità è implementata quando un sistema fa quello che ci si aspetta che faccia senza mostrare la complessità delle operazioni necessarie per portare a termine un compito apparentemente semplice come può essere una ricerca sul web.

Un sistema RESTful sta lontano. Non si sa bene quello che accade dietro le open API. Però a noi sta bene così perche’ tutto sembra più semplice. Però questo comporta una certa dose di fiducia da parte nostra verso il sistema. Abbiamo fiducia non solo che i nostri desideri vengano soddisfatti senza troppi fronzoli, ma anche che il sistema non faccia del male a noi o ad altri.

Quando progettiamo una nuvola di servizi RESTful, quindi, dobbiamo prestare attenzione a non tradire la fiducia degli utenti. Questo significa che le informazioni che gli utenti ci donano per semplificare alcuni aspetti della loro vita non devono essere usate contro gli utenti stessi o per fini diversi da quelli che gli utenti si aspettano.

Attenzione: anche se sembra che si tratti di un tema solo “etico”, questo aspetto è invece importante almeno quanto quelli più tecnici o di design. L’economia delle reti è un’economia che si basa sulla simbiosi e sulla fiducia [2]. Gli utenti e il sistema sono vicendevolmente utili gli uni agli altri. Il legame che li unisce è la fiducia.

C’era una volta in un regno lontano lontano un project manager disperato perche’ lo sviluppo del software sulla nuova piattaforma era più lento del previsto. Ogni notte i programmatori, armati di fucile a pompa e tazza di caffè, cercavano di respingere l’attacco degli Androidi, creature piccole come un insetto, mezze uomo e mezze macchina. Finche’ un bel giorno un consulente esterno arrivò in quel regno lontano lontano sul suo cavallo bianco dicendo “Qua ci vuole un Content Provider!”. “Content Provider” incominciò a ripetere il project manager. “Content provider!”, urlarono di gioia i programmatori. “Content provider” fu la parola che risuonò tra le mura del castello nei giorni successivi. Il project manager sperava che sarebbe bastato pronunciare quelle parole almeno due volte al giorno e con la giusta intonazione per respingere l’attacco degli Androidi. Però fu tutto vano. Non servì nemmeno sbattere due volte i tacchi delle scarpe. Forse avrebbero dovuto tentare la via esoterica, con il sacrificio di una vergine. Ma non riuscirono a trovarla nemmeno su Craigslist…

Il problema del povero project manager è quello di credere che una tecnologia, una persona o una parola di moda siano la panacea di tutti i mali. Un Content Provider è semplicemente uno strumento che permette di nascondere i dettagli di come un dato è memorizzato. Separare i concetti è una buona pratica di programmazione. Però un Content Provider non risolve il problema se i programmatori scrivono codice in modo approssimativo e disorganizzato e se prediligono il copia-e-incolla all’incapsulazione.

La favoletta degli Androidi non avrà un lieto fine ed è una storia purtroppo molto comune. Finora ho solo parlato bene di REST, ma farei lo stesso errore del project manager della favola se dicessi che REST risolve tutti i problemi. Un’architettura RESTful non è adatta ad ogni situazione. Dipende da quello che si vuole fare e spesso quello che si vuole fare non ha motivazioni tecniche. Per quanto riguarda il tema della semplicità esistono cose che non possono essere semplificate. Realizzare l’interoperabilità tra i sistemi informativi di una o più aziende non è banale. Spesso richiede l’utilizzo di strumenti molto complessi per orchestrare i diversi processi. In questo caso forse REST potrebbe fallire.

Quando REST è destinato a fallire? Non lo so e non credo che esista una regola generale. L’unica strategia è quella di provare a progettare e sviluppare un’architettura RESTful. Procedere a tentoni per imparare dai propri errori. Un piccolo esempio può essere dato ancora una volta dal mio robot Lego. Come ho già scritto le volte precedenti, è possibile controllare il robot attraverso delle richieste che contengono delle rappresentazioni in JSON delle risorse come i motori o i sensori. Sono soddisfatto del risultato generale, ma c’è un punto in cui il mio approccio RESTful alla programmazione del robot fallisce. Avrei voluto che il computer fosse in grado di inviare dei “comportamenti” predefiniti al robot, in modo tale che il robot potesse reagire agli eventi esterni senza bisogno di aspettare un ordine dal computer. Ad esempio, avrei voluto implementare una “frenata di sicurezza”: il robot si arresta immediatamente quando “si sente” mancare il terreno sotto i piedi (o i cingoli). Qualcuno ha costruito un robot simile usando i sensori di tocco [4]. Questo comportamento impedisce al pilota che controlla il robot da remoto di far cascare per disattenzione il Mars Rover in un cratere di Marte o, più verosimilmente, un prototipo del Mars Rover dal tavolo della cucina.

Seguendo sempre l’approccio RESTful, ho definito delle risorse che rappresentano dei “trigger”: a un evento (ad esempio, sensore di pressione alzato) corrisponde un’azione (ad esempio, ferma i motori). Eventi, azioni e trigger sono descritti come risorse che possono fare riferimento ad altre risorse (cioè i motori e i sensori). Nei casi più semplici, questa idea funziona molto bene. Però in situazioni più complesse il meccanismo si fa più complicato e oscuro. Questo è un brutto segno: la semplicità si distingue dalla banalità perche’ scala meglio. Può darsi che non sia possibile semplificare questa funzionalità e può darsi che un approccio RESTful non sia adatto in questo caso. Può anche darsi che non abbia pensato abbastanza a questo problema e che la soluzione sia più semplice del previsto. A volte basta affrontare il problema con la mente fresca per trovare soluzioni che sembravano impossibili. Insomma, se qualcuno di voi ha una mezza idea su come fare, sono ben felice di sapere come!

L’ultima legge riassume tutte le altre. La decima legge potrebbe anche essere l’unica. Quindi è un’occasione per fare il punto della situazione e ricapitolare quanto detto anche nelle puntate precedenti.

Riduci, Organizza e Tempo sono le prime tre leggi della semplicità. Abbiamo visto che possono essere utilizzate per spiegare i principi di design dello stile archietturale REST. In altre parole, la semplicità, come viene definita dalle prime tre leggi, è una proprietà emergente dei sistemi RESTful. La filosofia che ha guidato la formulazione di REST enfatizza il ruolo della semplicità della progettazione di un sistema software rispetto a tutte le altre qualità più tecniche, come la scalabilità o la modificabilità. Secondo me, l’essenza di REST, la sostanza che lo differenzia da altri stili architetturali, è proprio il peso dato alla semplicità come caratteristica desiderabile di un sistema software.

La semplicità però non è un aspetto tecnico o ingegneristico, ma di design. Progettare un’architettura RESTful è quindi qualcosa a metà strada tra il lavoro dell’ingegnere e quello del designer. Questo tema è approfondito da altre quattro leggi della semplicità: Impara, Differenze, Contesto ed Emozione. Un sistema è semplice quando fa quello che ci aspettiamo in modo intuitivo. Un sistema di questo tipo lo costruiamo mettendo in relazione concetti e utilizzando metafore di utilizzo. Dobbiamo capire cosa è necessario e cosa possiamo lasciare fuori. Solo così facciamo risaltare in modo intuitivo il significato implicito del sistema.

Le ultime due leggi, Fiducia e Fallimento, sono delle raccomandazioni generali che valgono per ogni cosa che si produce e non hanno ragioni tecniche o di buona pratica di design come le precedenti leggi. La semplicità è spesso nascondere la complessità, ma non possiamo usare questo trucco per ingannare gli utenti. Il sistema e gli utenti vivono in simbiosi e quindi nel loro rapporto deve esserci fiducia. Questa legge vale per qualsiasi prodotto, però sembra essere stata scritta apposta per dei servizi web dove il problema della privacy, o più in generale della fiducia, è alla base della loro economia.

Non bisogna nemmeno credere che REST sia un martello dorato che possiamo usare per risolvere ogni problema. Ci sono cose che non possono essere semplificate e dove lo stile REST può fallire.

Coerentemente con quanto detto fin qui, anche questa serie di articoli sullo stile REST può essere stata una fallimento. Anche se le leggi della semplicità hanno delle simulitudini con i principi e la filosofia REST, a volte, mentre rileggo, mi sembra che alcune mie considerazioni siano troppo forzate, altre un po’ ingenue. Quindi potrei aver fallito. Però il fallimento non deve essere visto come una sconfitta, ma come il punto di partenza da cui iniziare la discussione.

[2] Luca De Biase, “Economia della felicità”, Feltrinelli, 2007

[3] John Maeda, “The Laws of Simplicity”, 2006, trad. it.”Le leggi della semplicità”, Bruno Mondadori, 2006

[4] LEGO MindStorms NXT 2.0 Tabletop Roving Robot Demonstration