In questo articolo riprendiamo l‘analisi dello stile architetturale REST da un punto di vista insolito: la semplicità come caratteristica desiderabile di un sistema software. Il feedback ricevuto ci aiuta a capire dove vogliamo andare a parare. Ma in questo articolo continuiamo l‘analisi di quelle leggi della semplicità… che sono meno semplici di quel che sembrano.

Riprendiamo con questo secondo articolo della serie l’analisi dello stile architetturale REST [1]. Le restanti Leggi della Semplicità [2] sono meno chiare e i temi trattati si fanno più ambigui, come lo stesso professor Maeda ammette nel capitolo dedicato alla nona legge, quella del fallimento. Se le prime tre leggi sono chiare e inequivocabili, non è lo stesso per le altre e in base a ciò lo stile architetturale REST può essere letto attraverso più interpretazioni delle ultime leggi; non sappiamo dire con certezza quali siano le interpretazioni “vere”. Riprendiamo quindi il nostro cammino attraverso le Leggi della Semplicità, esaminandone alcune altre e facendo attenzione a non scivolare sul terreno che da qui in poi si fa più viscido e paludoso.

A differenza delle prime tre leggi, è difficile trovare un’associazione o delle analogie con i sei vincoli REST per le restanti sette. Credo invece che l’ultima parte del libro di Maeda sia più utile per capire come progettare interfacce verso gli utenti. Come abbiamo detto nell’articolo precedente, lo stile REST non è prerogativa di una particolare tecnologia o di un dominio applicativo. Però, in questi tempi “nuvolosi”, le architetture RESTful vengono utilizzate soprattutto per esporre servizi rivolti agli utenti.

IV. Impara: la conoscenza rende tutto più semplice

Di sicuro avete partecipato alla presentazione di un progetto dove il project manager insisteva a notare la complessità e la difficoltà che lui e il suo team avevano incontrato nello sviluppo e nella progettazione di un certo prodotto software. In genere è una strategia da evitare per vendere un prodotto in quanto annoia il pubblico che non è interessato ai retroscena, ma vuole solo capire perche‘ dovrebbe comprare.

Raccontare la storia della progettazione di un prodotto è un errore che molti fanno e forse tutti abbiamo fatto almeno una volta nella nostra vita. Io ho sempre creduto che questa strategia sbagliata sia il tentativo maldestro di trasmettere il valore presunto di un prodotto mostrando ogni singola goccia di sudore versata. Da un po’ di tempo, però, ho trovato un’altra spiegazione possibile. Il project manager vede solo la complessità del prodotto perche‘ non lo comprende, non conosce la tecnologia, non capisce come funziona il software. Tutto è più semplice quando si conosce. Al contrario, tutto appare più complesso quando non si è imparato abbastanza. Questa regola vale per il software come per allacciarsi le scarpe o fare addizioni ed è la quarta legge della semplicità.

Una buona architettura RESTful non ha bisogno di essere imparata e non necessita di un corposo manuale di istruzioni. L’utilizzo dei servizi deve essere intuitivo e può essere compreso immediatamente perche‘ sembra famigliare. Il professor Maeda definisce questo processo di comprensione “approccio del designer” e lo contrappone al più rude “approccio dell’ingegnere” che richiede invece la consultazione di un manuale.

“Il design sfrutta l’instinto umano di cercare relazioni, le traduce in oggetti utili e tangibili e alla fine aggiunge un po’ di sorpresa per far sì che lo sforzo dei fruitori non sia stato vano” [2]

Come raccontavo nel precedente articolo, il mio robot Lego [5] è stato progettato tenendo conto dei principi REST. I sensori e i motori sono visti come risorse. Anche il robot stesso è una risorsa composta da altre risorse. Quando chiedo di leggere lo stato di un motore mi aspetto di ottenere una descrizione delle informazioni rilevanti su quel motore. Ad esempio,

GET /motor/A

mi restituisce una descrizione simile a questa

{ "speed":1, "forward":false }

Quindi, seguendo sempre la stessa metafora, mi aspetto che sovrascrivere lo stato del motore mi permetta di controllare i movimenti del robot

PUT /motor/A {"forward":true}

E infatti il robot incomicia a muoversi in avanti accendendo il suo motore centrale.

Una volta che si è capito il meccanismo, è semplice intuire come far muovere due motori. Ed è una soddisfazione vedere che il robot fa proprio quello che noi vogliamo che faccia!

PUT /motor/ { "A":{"forward":true}, "B":{"forward":true} }

V. Differenze: la complessità e la semplicità sono necessarie una all’altra

Facendo memoria delle esperienze accumulate durante i miei studi, ricordo che fra compagni di classe, credo pressapoco al secondo anno d’asilo, si diceva che gli stupidi servono perche‘ altrimenti non esisterebbero nemmeno gli intelligenti. Allo stesso modo, la complessità e la semplicità sono necessarie perche‘ si complementano una con l’altra. Senza la complessità non potremmo riconoscere la semplicità quando la vediamo.

La complessità con la quale abbiamo a che fare quando progettiamo un’applicazione web è la complessità della realtà. I clienti ci perseguitano con requisiti sempre nuovi e noi dobbiamo pensare un’infinità inesauribile di possibilità e alternative mentre diventa sempre più difficile orientarsi e organizzare in modo coerente i concetti che il sistema esprime. Lo stile REST, per prima cosa, semplifica tutto questo costringendoci a focalizzarci solo sul concetto di risorsa e riducendo il numero di azioni a un insieme piccolo ma significativo. Grazie al confronto con la realtà, riusciamo ad apprezzare meglio lo stile REST.

SOA, SOAP, OWL, ESB, BPEL, Semantic Web, orchestrazione, Zang, Tumb, Tumb. Tutto questo in REST non c’è, o almeno è messo in secondo piano, molto lontano. La semplicità di REST viene evidenziata anche nel confronto con la complessità di altre tecnologie o altre filosofie concorrenti.

VI. Contesto: ciò che sta alla periferia della complessità non è assolutamente periferico

“La proliferazione dei requisiti deve essere combattuta, sia attraverso il controllo delle nascite che attraverso l’infanticidio” [3]. Le parole volutamente provocatorie sono di Fred Brooks, vincitore del Turing Award nel 1999 e ingegnere del software di fama internazionale.

Il manager inesperto punta a raggiungere la completezza funzionale nella progettazione di un certo prodotto. Ma è un’impresa utopica destinata a fallire. Non è il numero di caratteristiche di un prodotto a fare la differenza. L’iPod ha meno funzionalità di un concorrente lettore MP3, ma costa di più. Quello che importa è l’integrità concettuale. L’integrità concettuale è coerenza e consistenza nei concetti di un prodotto che “fa quello che uno si aspetta che faccia” [3]. Quindi l’integrità concettuale si collega con la IV legge (Impara). Però c’è qualcosa di più che richiede una nuova legge: il Contesto.

Questo qualcosa in più è in realtà qualcosa in meno. Il valore del nulla. Quello che il sistema non è e non ha. Il vuoto mette in risalto quello che rimane. Secondo la teoria dell’informazione di Shannon tutto ha meno contenuto informativo di poco. In altre parole meno cose hanno più significato. Quando un sistema ha poche funzionalità ben organizzate e coerenti, l’utente può dedicare più attenzione a quel che rimane e che forse non è detto esplicitamente perche‘ è alla periferia della semplicità. Può sembrare solo filosofia, ma nella pratica, se ci fate attenzione, il vuoto fa risaltare la “user experience”.

Un esempio in tal senso è il sito Foodspotting [4] che offre come servizio la possibilità di suggerire o trovare cibi deliziosi in una città. Prendo come esempio uno dei principi ispiratori del progetto.

“[Il servizio] riguarda solo il cibo. Non riguarda il posto, il prezzo, quel che ci sta attorno, la gente o il valore nutrizionale: è un servizio solo sul buon cibo e su dove trovarlo”.

La tentazione di aggiungere informazioni sul posto e il prezzo è forte quando si fa l’analisi dei requisiti di un sito di questo genere. Però il costo di un servizio più completo in termini funzionali è una minore caratterizzazione del servizio stesso. Dire “ciò che il sito non è” descrive invece meglio l’esperienza d’uso che il sito offre agli utenti.

Identificare le risorse di un sistema RESTful è un compito delicato che richiede un certo “gusto” nello scegliere i concetti adatti per raccontare qual è l’esperienza d’uso che si indende offrire. Ho usato il verbo “raccontare” non a caso, si racconta un sistema agli utenti come si racconta una storia ad un bambino. Questo è difficile da capire perche‘ scrivere codice è considerato dai più un fatto meramente tecnico. Io credo che programmare sia invece una forma di espressione.

In un’architettura RESTful client e server sono disaccoppiati. Questo significa che il client ha un proprio modello dei dati e una propria business logic che dipende da quella del server, ma aggiunge elementi e regole sue proprie. Un’obiezione banale è che in questo modo si corre il rischio di avere tanti client sviluppati da persone diverse che fanno quello che vogliono e non riescono a comunicare tra di loro. Non sono d’accordo. L’importanza del contesto è tutta qui. Il contesto deve trasmettere in modo intuitivo e familiare quello che il sistema vuole e deve essere. In altre parole, guida da lontano la progettazione dei client che seguono un modello semantico comune implicito nella descrizione delle risorse e delle azioni dell’architettura RESTful.

La progettazione di servizi RESTful segue l'”approccio del designer”: cioè mette in relazione concetti diversi creando metafore intuitive e di immediata comprensione. Questa potrebbe essere un’alternativa all’interoperabilità semantica dei sistemi distribuiti che al giorno d’oggi segue invece l'”approccio dell’ingegnere” in quanto prevede la costruizione esplicita di complesse ontologie che richiedono studio e molto lavoro e fatica per costruirle e mantenerle.

In questa seconda parte della nostra storia sullo stile REST abbiamo analizzato tre nuove leggi della semplicità: Impara, Differenze e Contesto. Mentre le prime tre leggi giustificavano la scelta dei vincoli architetturali di REST, le leggi discusse in questo articolo ci dicono come progettare una piattaforma di servizi RESTful. La lezione che possiamo imparare dal piccolo libro del professor Maeda è la seguente: il designer di una piattaforma si servizi RESTful deve rendere intuitivo l’uso del sistema modulando complessità e semplicità. Nella prossima puntata concluderemo il nostro racconto con le ultime quattro leggi della semplicità.

[1] Voce “Representational State Transfer” su Wikipedia

http://en.wikipedia.org/wiki/Representational_State_Transfer

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

[3] Frederick Brooks, “The Design of Design”, Addison-Wesley, 2010

[4] Il sito dei “foodspotters”

Marco Stenico

Laureato in (Bio)Informatica presso l‘Università di Trento con il massimo dei voti e la lode, ha ben presto smesso di credere nelle scienze naturali. Da allora ha solo commesso errori. Cosa di per sé non negativa perché dall‘esperienza ha imparato a non ripetere mai più quegli errori. Tuttavia continua a scoprirne altri completamente nuovi e originali.
Vita miserrima e sfortunata per il nostro programmatore errante perché di solito tutti i progetti sono un successo. Specialmente se, come spesso accade, a giudicarli è chi li pensa e li sviluppa. Per questa ragione ha deciso di voler capire perché i progetti falliscono e qual è la natura degli errori che si commettono durante la progettazione e l‘implementazione del software.