Anagrammi e linguistica computazionale

Il gioco degli anagrammi affonda probabilmente le radici nella Qabbalah ebraica.

Oggi si dice "algoritmo" e "gamification" ma, nel 1611, quando il religioso corso Giovan Battista Agnesi, pubblicò un migliaio di combinazioni anagrammatiche ad argomento religioso (come Angelus Dei te puram vocat, anima mira -> Alma Virgo et pia Mater, unica munda est) quello degli anagrammi era una vera e propria Ars, probabilmente derivata dai cabbalisti ebrei, atta a scoprire il significato nascosto delle parole.
Oggi il problema degli anagrammi ha perduto ogni connotazione mistica (o quasi) ma continua a dilettare chi cerca di progettare algoritmi efficienti, o chi, come Umberto Eco, si diverte in questo gioco, arrivando a scrivere composizioni i cui versi sono tutti anagrammi.
In particolare, qui ci si domanda se e come sia possibile eseguire quante più permutazioni anagrammatiche, data una frase in una lingua qualsiasi. In altre parole, fissato un dizionario di tutte le parole lecite in una determinata lingua, ci si chiede quale sia il metodo più efficiente per derivare, da una frase che abbia senso compiuto, un'altra frase, anch'essa di senso compiuto e contenente le medesime lettere della prima, con la stessa frequenza.
Il problema può essere scomposto in due parti: la prima in cui, data la frase di partenza assieme a un dizionario della lingua in cui è scritta (che eventualmente includa anche i lemmi inglesi di maggior utilizzo), si cercano tutte le parole derivabili da essa; la seconda in cui, da tutte le parole trovate nel primo step, se ne cerca una combinazione che abbia "senso compiuto" (per il momento per semplicità tralasciamo di definire rigorosamente cosa possa significare avere una frase di senso compiuto nella lungua L). metodologicamente, mentre la prima parte è un problema scacchistico ovvero di "constraint satisfaction", quest'ultima parte, si comprende bene, riguarda l'intelligenza artificiale e la linguistica computazionale.
Sul primo problema, ho trovato utile l'applicazione dell'algoritmo di Backtracking (per intenderci quello che si usa per risolvere in automatico i Sudoku e che usano anche molti simulatori di scacchi). Ad esempio questo sito ne utilizza - per frasi di relativamente poche lettere per ovvi motivi computazionali) una brillante e efficiente versione di Giovanni Resta (ricercatore all'IIT-CNR di Pisa), con un dizionario italiano esteso di 270K lemmi circa.
Sul mio GitHub ho messo una implementazione in Python per i più curiosi.
Resta da affrontare la seconda sfida, generalizzandola il più possibile per le lingue di maggiore utilizzo. In questo ho trovato molto utile il natural Language ToolKit di Python ma c'è tanto da lavorare. Se a qualcuno interessa approfondire, contattatemi in privato!

PS: Il prete GB Agnesi citato all'inizio di questo post era cieco e non aveva processori da sfruttare, eccetto i suoi neuroni. Credo che difficilmente riusciremo a fare meglio di lui ma ci si può provare ;)

Accedere a Twitter mediante le Streaming API e StreamR

Twitter mette a disposizione potenti API attraverso le quali è possibile interrogare lo stream dei tweet e filtrarli attraverso una grande varietà di opzioni quali la geolocalizzazione, gli hashtag, la lingua e così via.
Una panoramica generale sulel API di Twitter la trovate sul portale dedicato agli sviluppatori. Qui ci interessa spiegare i dettagli su come connettersi alle API di Twitter da una applicazione R adoperando la libreria StreamR. Le API di Twitter richiedono una connessione OAuth in cui è necessario innanzitutto accreditare la propria applicazione. Maggiori approfondimenti sul funzionamento di OAuth li potete trovare in un precedente articolo di questo blog.

1) Creare una nuova App. Per affrontare questo passaggio è necessario avere un account Twitter al quale saranno legate tutte le vostre applicazioni. Potrebbe essere il caso di creare un account ad hoc, ovvero di usare il vostro account personale per fare delle prove, siete liberi di giudicare caso per caso quale soluzione fa più al caso vostro. Una volta fatto login, andate all'URL https://apps.twitter.com/ e aggiungete una nuova applicazione (Create new App). Nella pagina successiva comparirà una form in cui inserire informazioni riguardo la vostra applicazione e accettare le policy di licenza di Twitter. A questo punto andate sul panel "Keys and Access Tokens" dove sono disponibili "Consumer Key" e "Consumer Secret" per la vostra App. Queste informazioni andranno inserite nell'applicazione e sono necessarie per effettuare l'handshake con le API. Ad esse vanno aggiunti il Token di accesso che vengono generati cliccando sul pulsante "Generate access token" nello stesso panel. Saranno così creati due nuovi codici "Access token" e "Access token secret" che serviranno sempre nelle operazioni di handshake.

2) OAuth handshake. A questo punto prepariamo lo script R che effettuerà l'handshake con Twitter. Dopo aver installato e caricato le librerie necessarie dal repository CRAN (TwitteR, RCurl, streamR, rjson e ROAuth) con le relative dipendenze, dichiariamo le variabili di accesso alla nostra App:

requestURL    <-  "https://api.twitter.com/oauth/request_token"
accessURL     <-  "https://api.twitter.com/oauth/access_token"
authURL       <-  "https://api.twitter.com/oauth/authorize"

l_consKey     <-  "la vostra consumer key";
l_consSecret  <-  "la vostra consumer secret";
l_token       <-  "il vostro access token";
l_tokenSecret <-  "la vostra access token secret";

download.file(url="http://curl.haxx.se/ca/cacert.pem", destfile="cacert.pem")
my_oauth <- OAuthFactory$new(consumerKey=l_consKey, consumerSecret=l_consSecret,
                             requestURL=requestURL, accessURL=accessURL,
                             authURL=authURL)
my_oauth$handshake(cainfo = system.file("CurlSSL","cacert.pem",
                             package = "RCurl"))

A questo punto, R chiederà di eseguire un passaggio di autenticazione via browser: dovrete eseguire il login a Twitter e vi sarà dato un pin numerico da riportare nella consolle di R allo scopo di autorizzare l'accesso della applicazione R al vostro account Twitter. Eseguito questo step viene popolato l'oggetto my_oauth contenente le informazioni di autenticazione alle API coi relativi token. Per non dover rifare ogni volta questo passaggio è consigliabile salvare queste informazioni in un file:

save(list="my_oauth", file="twitteR_credentials")

che può poi essere richiamato all'occorrenza:

load("twitteR_credentials") 

3) Accesso da un proxy. Se vi trovate a sviluppare in un ambiente protetto da proxy che magari richiede anche una autenticazione, è necessario premettere ai passaggi precedentemente descritti le necessarie configurazioni per permettere a curl di raggiungere l'endpoint di Twitter. Questa operazione può essere fatta come segue:

opts <- list(
  proxy         = "indirizzo del vostro proxy",
  proxyusername = "vostra username",  #se usate un dominio sarà 
                                       "dominio\\username"
  proxypassword = "vostra password",  #password di autenticazione al proxy
  proxyport     = porta del proxy
)

options(RCurlOptions = opts)

ATTENZIONE! C'è da dire che spesso l'operazione di handshake è problematica quando ci si trova dietro un proxy. Talvolta, in dipendenza dalle configurazioni del proxy stesso, lo scambio dei token fra client e endpoint non avviene correttamente a causa di firewall e callbacks col risultato che l'handshake fallisce (con un errore 407). Nel nostro caso, ad esempio, non siamo stati in grado di risolvere il problema di far avvenire l'handshake dietro al proxy, tuttavia abbiamo risolto con un workaround che consiste nell'aver generato l'oggetto my_oauth su una macchina non protetta dal proxy e successivamente nell'aver portato il file con l'oggetto salvato (nell'esempio è twitteR_credentials) nell'ambiente protetto. Il problema principale sta nel fatto che la libreria StreamR consente l'autenticazione solo mediante ROAuth, il quale è un metodo quasi del tutto deprecato in vantaggio di httr. Tuttavia, al mometo della scrittura di questo articolo, StreamR non funziona sotto httr, nonostante abbiamo aperto alcuni ticket nella community di Twitter non abbiamo ancora ricevuto risposta. Se qualcuno fra i nostri lettori dispone di una soluzione al problema lo incoraggiamo a suggerircela nei commenti. Portare il file di accesso nell'ambiente proxy invece ha fatto in modo che la nostra applicazione funzionasse correttamente.

4) Download e sfruttamento dei dati. Una volta in possesso dell'oggetto di autenticazione (che nell'esempio abbiamo chiamato my_oauth), possiamo usare la libreria streamR per scaricare (su disco o in memoria) i dati da twitter. Ad esempio, l'istruzione:

filterStream( file="tweets_rstats.json", track="rstats",
     locations=c(-74,40,-73,41), timeout=600, language="en", 
      oauth=my_oauth )

Apre uno stream che dura 600 secondi e scarica tutti i tweet in lingua inglese che menzionano il termine "rstats" e che sono inviati dalla regione di New York, identificata dalle coordinate espresse col vettore assegnato al parametro locations. Il risultato viene salvato in un file json.

Ulteriori esempi sono disponibili sulla guida del pacchetto streamR disponibile sul repository CRAN.

La Blockchain spiegata. Cosa è? Come funziona? Come si usa?

Blockchain è diventata una parola magica: la si sente praticamente dappertutto, dagli ambienti tecnologici alla finanza. Addirittura si sente affermare (e non è una esagerazione nella opinione di chi scrive) che la Blockchain rivoluzionerà il mondo più di quanto abbia fatto Internet stessa. Ciò nonostante, cosa sia effettivamente è un concetto ancora sfuggente ai più.
Sul web si trovano spiegazioni assai complete ma molto tecniche assieme a spiegazioni semplici ma troppo generiche. Proviamo qui a fare un po' di chiarezza e sintesi, mettendoci in una posizione intermedia fra questi estremi. Chiedo scusa in anticipo agli esperti di blockchain che certamente troveranno inesattezze o semplificazioni estreme in quanto ho scritto, d'altra parte meglio un articolo un po' imperfetto ma esistente che uno non esistente perché mai perfetto abbastanza! Take it easy ;)

Generalità
Innanzitutto chiariamo che la Blockchain nasce col Bitcoin e ne costituisce la tecnologia core, ma qui non parleremo di Bitcoin, se non in maniera molto superficiale e come esempio, poiché questa criptocurrency non è che una singola applicazione della blockchain: la Blockchain sta a Bitcoin come Internet sta alla e-mail. Ci interessa qui essere più generali (ma non generici) e comprendere cosa sia nel dettaglio la blockchain, come funziona e perché funziona.
In termini tecnici, la Blockchain è un database contenente transazioni, distribuito su svariati server. Ciò significa che, per quanto grande possa essere questo "diario delle transazioni" esso è replicato migliaia di volte su migliaia di server, geograficamente distribuiti, chiamati "nodi". Ossia la Blockchain è un registro di transazioni implementato su un sistema infrastrutturale di grandi dimensioni, distribuito su scala geografica, sul quale è possibile costruire applicazioni. E queste, per loro stessa natura, possono essere le più svariate possibili.
Per comprendere meglio i dettagli della Blockchain è necessario avere ben chiaro cosa sia una transazione. Questo termine ha diverse accezioni in campo giuridico, legale, economico e informatico; qui ci interessa per il momento quest'ultima. Vedremo in seguito però che la tecnologia implementata dalla Blockchain può servire applicazioni che si occupano dei più disparati tipi di transazioni.
In IT, il termine transazione deriva dalla teoria dei database relazionali. Sostanzialmente, in questo ambito, una transazione è un insieme di operazioni di lettura-scrittura effettuate sui dati; il complesso di queste operazioni deve garantire che, in caso di successo, il risultato sui dati deve essere persistente, mentre, in caso di insuccesso, tutto deve tornare allo stato preesistente, ossia come se la transazione non avesse mai avuto inizio. Questa caratteristica delle transazioni è garantita da un insieme di proprietà dette ACID, acronimo che sta per Atomic, Consistent, Isolated, Durable. In altri termini, una transazione che sia veramente tale deve essere: 1) Atomic; ossia atomica: sebbene composta da sotto operazioni, la sua esecuzione deve essere completa o nulla, non sono ammesse esecuzioni parziali. 2) Consistent; questa proprietà sta a indicare che lo stato della base dati deve rimanere coerente prima e dopo la transazione, sia che questa si concluda in modo corretto, sia che venga abortita. Cioè la transazione non deve in nessun caso corrompere i dati, violare vincoli di integrità o qualsiasi altra modifica che alteri lo stato della base dati preesistente alla transazione. 3) Isolated; questa proprietà indica che ciascuna transazione deve essere eseguita in un contesto indipendente da ogni altra transazione di modo che l'eventuale fallimento di una transazione non possa influire sull'andamento di altre transazioni che le sono simultanee. 4) Durable, che in italiano possiamo tradurre con Persistente; una volta che la transazione si sia conclusa con successo, questa modifica deve essere salvata in modo persistente sulla base dati, ossia non deve essere più smarrita per alcun motivo.
Un esempio banale di transazione può essere un pagamento con carta di credito: se il pagamento va a buon fine l'importo sarà inesorabilmente scalato dal conto, se non va a buon fine lo stato del conto deve essere quello preesistente al pagamento. Inoltre il pagamento deve essere isolato da altri pagamenti simultanei e il suo effetto deve essere persistente sul conto. Nessuno accetterebbe di effettuare un pagamento se non fossero assicurate tutte le proprietà ACID che definiscono il concetto stesso di transazione.
A questo punto che abbiamo un po' più chiaro il concetto stesso di transazione, chiediamoci chi è che decide se l'esito di una transazione è positivo o negativo. In altre parole, tornando all'esempio fatto, quando ci accingiamo a pagare con la nostra carta di credito, chi è che decide se la transazione avrà successo o, al contrario, verrà respinta? Nel caso degli attuali sistemi di pagamento transazionali, esiste una terza parte che garantisce l'esito della transazione. Ad esempio garantisce che il cliente sia effettivamente chi dichiara di essere, possieda effettivamente il denaro per pagare e così via.
La Blockchain è fatta in modo che per verificare l'esito di una transazione non sia necessaria una terza parte fidata, ma fa in modo che sia il sistema stesso a decidere. Ma come? Poniamo qui l'accento soprattutto sul termine "fidata", trusted in inglese, poiché questo è un punto cruciale. Se la terza parte che valida la transazione non è fidata cade l'intero meccanismo che sta alla base della transazione, cioè non saremmo davvero più in grado di dire se una transazione sia valida o meno.
Per comprendere meglio questo aspetto cruciale, proviamo per un attimo a estendere il concetto di transazione ai più svariati aspetti del commercio. Ossia, allo scambio di beni e servizi che oggigiorno avviene su scala planetaria alla velocità di Internet. Transazioni sono pertanto gli acquisti su un sito di e-commerce, un bonifico online, la cessione di un immobile, perfino un comune pagamento in contanti e quant'altro ci viene in mente.
Nel mondo reale, per ratificare la validità di una transazione ricorriamo a banche, notai, organismi finanziari, banconote. Questi organismi sono chiamati terze parti fidate (trusted third parties), ad esempio, la Banca Centrale Europea (BCE) garantisce che le banconote che abbiamo nel nostro portafogli abbiano un certo valore che è sostanzialmente stabile nel tempo e che queste banconote saranno accettate come sistema di pagamento in tutta quella parte dell'Unione Europea che ha adottato l'Euro come moneta. Queste terze parti hanno però diversi svantaggi, uno su tutti: per ratificare le transazioni normalmente richiedono il pagamento di una somma di denaro, non sono cioè gratuiti, hanno un costo (chiunque sia andato da un notaio sa di cosa parlo) e, per di più, quanto sono realmente trusted? Chi verifica il grado di fiducia che possiamo ragionevolmente riporre in una terza parte?
Per avere una sensazione di quanto queste domande siano profonde, basterà citare le origini della criptocurrency Bitcoin. Questa, come è noto, nacque nell'autunno del 2008, subito dopo il crack della Lehman Brothers e la conseguente crisi che ne derivò, crisi soprattutto di fiducia proprio in quegli organismi di terze parti che avrebbero dovuto verificare ma che evidentemente avevano fallito nella loro missione. E tutto il sistema ne pagò le consegiuenze mostrando che nell'economia attuale la crisi della fiducia fra i partecipanti del mercato porta a conseguenze disastrose: nessuno si fida di nessuno, nessuno presta più denaro a privati o aziende e l'intera economia collassa. Fu ciò che avvenne in quel 2008 quando, non per caso, comparve l'ormai storico articolo di Satoshi Nakamoto (probabilmente un nickname visto che il vero autore, o autori, della Blockchain restano tuttora anonimi), che prometteva un sistema di moneta elettronica peer-to-peer che avrebbe consentito pagamenti online "senza passare attraverso istituzioni finanziarie".
Ecco il punto centrale: con l'adozione di una moneta virtuale come Bitcoin, questa terza parte fidata non è un ente particolare bensì un registro pubblico (Ledger) che tiene traccia in tempo reale di tutte le transazioni da sempre effettuate con Bitcoin. Questo registro è memorizzato in una rete distribuita di calcolatori ed è disponibile a chiunque. In definitiva chiunque può consultare o scaricare il registro e letteralmente seguire il percorso fatto da ciascun singolo Bitcoin dalla sua creazione fino all'ultima transazione in cui è stato utilizzato.
Nel caso dell'applicazione Bitcoin, la Blockchain coincide con questo registro. O, per meglio dire, ne costituisce la tecnologia fondante.
Essendo memorizzata in migliaia di nodi e aggiornata in modo pubblico e pressoché simultaneo su ciascun nodo, la Blockchain garantisce che una determinata transazione è realmente avvenuta. Se, per esempio, un agente malevolo tentasse di attaccare un nodo, o di falsificare anche una sola transazione, ad esempio atta a dimostrare di possedere un quantitativo di Bitcoin che in realtà non ha, ecco che i rimanenti nodi non sarebbero allineati su quella transazione che pertanto produrrebbe il fallimento di ogni altra transazione successiva che tentasse di "spendere" quei Bitcoin non realmente posseduti. Questa verifica, fatta in maniera distribuita su migliaia di nodi, viene eseguita da programmi detti Miner che utilizzano allo scopo un complesso algoritmo matematico. Solo se la maggioranza di nodi è d'accordo la transazione è valida. È come se esistesse un registro pubblico contenente tutti gli estratti conto in euro, completi di movimenti, attraverso il quale è possibile tracciare il movimento di ogni singolo euro e verificare se, per esempio, ogni partecipante a una transazione possiede davvero la soma di denaro necessaria. È come se un notaio virtuale, distribuito e non controllabile da nessuno (governo, banca o azienda privata) ratificasse ogni singola transazione, ma senza alcun costo aggiuntivo per gli utenti.
Il punto di forza di questa tecnologia è che la Blockchain non fa distinzione se si sta parlando di moneta (reale o virtuale) o di un qualsiasi altro bene che può essere scambiato nel mondo reale. Ad esempio gli utenti della Blockchain possono decidere che un elemento di scambio è una somma di denaro, un certificato di proprietà o quant'altro.
Ma, come abbiamo premesso, non vogliamo qui focalizzarci sui Bitcoin ma solo comprendere il modo di funzionare della Blockchain. Quindi facciamo anche un altro esempio in cui la Blockchain può costituire l'infrastruttura tecnologica in grado di ospitare applicazioni trusted per il mondo reale.
Pensiamo al sistema di voto: la tecnologia Blockchain può tenere traccia delle schede elettorali facendo in modo che ogni votante, pur conservando l'anonimato, esprima la sua preferenza solo una volta e che, viceversa, ciascuna scheda possa contenere un unico voto. Oppure pensiamo a un sistema che consenta di tracciare le gemme con un identificativo che ne esprima la provenienza, la lavorazione e ogni passaggio di proprietà, dalla produzione al gioielliere a ogni altro acquirente successivo. Un sistema simile previene la frode perché ogni gemma avrebbe una identità e una provenienza del tutto pubblica e verificabile direttamente consultando la Blockchain. Pensiamo ancora a un sistema che possa garantire la provenienza di un pezzo di carne, di una verdura o di un barile di petrolio. Simili applicazioni già esistono e sempre di più ne verranno create man mano che la tecnologia diverrà più matura.

Implementazione
In questo paragrafo scenderemo nei dettagli implementativi della tecnologia Blockchain e sono richieste alcune nozioni di base della teoria delle basi di dati e di crittografia.
La Blockchain è un database. In particolare, è un database distribuito su migliaia di nodi, ad accesso pubblico, crittografato per garantirne la sicurezza, costantemente sincronizzato allo scopo di tenere costantemente aggiornate le transazioni.
La Blockchain deve il suo nome al fatto che le informazioni al suo interno (una somma di denaro, la prova di un'avvenuta transazione bancaria come un bonifico, ma anche un contratto, una scheda elettorale, una identità digitale, un certificato di autenticità e quant'altro possa venirci in mente) sono immagazzinate (letteralmente programmate) in blocchi, ciascuno dotato di timestamp e identificativo univoco e legati uno all'altro in una catena (chain, appunto) in maniera crittografica attraverso l'hash del blocco precedente, il che garantisce la sicurezza e la consistenza delle informazioni in quanto l'hash cambia se per qualsiasi motivo un blocco viene alterato o corrotto. Le identità stesse dei partecipanti alla Blockchain sono generate localmente e non esiste alcun registro centralizzato che possa essere corrotto o attaccato.
In che modo il sistema è attaccabile? Ad esempio mediante pseudospoofing o Sybil attack, un attacco informatico in cui un hacker crea un grande numero di identità fittizie su un sistema peer to peer allo scopo di guadagnare influenza, il che su un sistema basato sulla reputazione, ha valore critico. Blockchain contrasta questa debolezza rendendo onerosa la creazione di identità digitali, ossia richiedendo una grande quantità di calcolo e risorse fisiche e reali (come l'elettricità consumata per alimentare i server). Questa Proof of Work (PoW), ad esempio hashcash, viene espressamente richiesta per approvare una transazione su Blockchain e l'algoritmo matematico che sta alla base della tecnologia decide che, in presenza di più copie della Blockchain disallineate, ciascun nodo deve preferire quella che presenta più PoW. Il sistema così è robusto in quanto nessun individuo o piccolo numero di individui può avere una potenza di calcolo superiore al 50% dei partecipanti alla Blockchain pertanto una transazione che sia validata dal 50%+1 dei nodi è dichiarata trusted.
Ovviamente, man mano che avvengono le transazioni e vengono registrate nella catena, la lunghezza e la complessità della Blockchain aumenta. Questo rende problematico la sincronizzazione in tempo reale di migliaia di nodi e soprattutto rende sempre più costoso il PoW richiesto, rendendo meno accessibile l'uso stesso della tecnologia. Queste issues sono tuttora aperte e si aggiungono alle perplessità rimostrate da numerose istituzioni che sono preoccupate per le vulnerabilità di un sistema che si propone di soppiantarle a favore di un modello puramente peer to peer.

Conclusioni
La Blockchain è oggi una realtà e introdurrà vere e proprie rivoluzioni nel modo in cui scambiamo informazioni e asset attraverso la rete. Troppo spesso mitizzata, come tutte le tecnologie soffre di controindicazioni e punti di debolezza che non vanno mai dimenticati. Il primo passo è conoscere, il secondo è studiare. Per il primo crediamo di aver dato un piccolo contributo con questo articolo, per gli altri è necessario aggiornarsi di continuo. D'altra parte il web è letteralmente pieno di risorse da esplorare.
Qui di seguito vi segnaliamo alcune interessanti applicazioni e startup che usano una implementazione open di Blockchain chiamata Blockstack.

• Onename: applicazione per la gestione di identità digitali basata su Blockchain. 
• LaZooz: applicazione per la mobilità urbana.
• Ujo Music: interessante startup peer-to-peer per musicisti.

RESTful applications in Spring MVC

Questo primo tutorial si occuperà di introdurre lo stile architetturale denominato REST e di presentarne una semplice implementazione usando Spring MVC.
Per comprendere al meglio questo tutorial è consigliabile avere una certa dimestichezza con il linguaggio Java e Spring framework, con le specifiche del protocollo HTTP e con il pattern Inversion of Control.

Cosa si intende per REST? L'acronimo sta per Representational State Transfer e si riferisce ad un paradigma architetturale con cui realizzare applicazioni web basate su HTTP. Le applicazioni web realizzate usando REST vengono chiamate RESTful.
Questo paradigma pone al centro di tutto le risorse. Cosa è una risorsa? Praticamente tutto è una risorsa! Qualunque informazione immagazzinata nel nostro database lo è, qualunque dato possediamo e desideriamo condividere. Nel paradigma REST le risorse sono identificate rigorosamente ed accedute mediante URI attraverso una unica astrazione o interfaccia uniforme: quella del protocollo HTTP. Ad esempio per fare un fetch di tutti gli ordinativi del nostro DB effettueremo una request di tipo:

GET /orders

Similmente, si useranno gli altri "metodi" tipici del protocollo HTTP:

- GET /orders/1  per selezionare l'ordine con id=1;
- POST /orders  per inserire un nuovo ordine;
- PUT /orders/1 per fare update dell'ordine avente id=1;
- DELETE /orders/1 per cancellare l'ordine avente id=1;
- GET /customers/1/orders per selezionare tutti gli ordini relativi al cliente con id=1;

Ovviamente le risorse possono essere di vario tipo, cioè avere diverse rappresentazioni (es. testo, un documento pdf, un'immagine, multimedia ecc.) anche se è consigliato utilizzare tipi standard per i quali esiste una vasta gamma di casi d'uso, rispetto ai tipi più "esotici".
Il tipo di risorsa viene specificato nella request header, mentre il tipo di rappresentazione in risposta viene mostrato nel Content-Type e questo lo vedremo bene nel codice.
La cosa interessante in tutto ciò è che il server non mantiene alcuna informazione di stato! In altri termini, il paradigma REST non usa la sessione. I client mantengono lo stato attraverso le chiamate, nel senso che le risorse vengono fornite già corredate di links (ovviamente provvisti dal server) così da garantire le transizioni di stato del client. Ad esempio, se l'ordine avente identificativo 109 è stato fatto dal cliente con id=12 e contiene gli oggetti con id 1200 e 1567, alla richiesta GET /orders/109 il server risponderà con qualcosa del tipo:

<order ref="/orders/109">
    <customer ref="/customers/12"/>
    <lineItems>
          <lineItem item="/catalog/item/1200" qty="2"/>
          <lineItem item="/catalog/item/1567" qty="8"/>
    </lineItems>
</order>

In cui si vede chiaramente che ogni risorsa è legata ad un URI che consente al client di ricostruire sempre le transizioni di stato. Da ciò si comprende come sia indispensabile, in fase di progettazione di una applicazione RESTful, una corretta definizione degli URI legati a tutte le risorse.
Se questo semplifica le cose in quanto disaccoppia drammaticamente il lato client dal lato server (con tutti i vantaggi legati ad un loose coupling come ad esempio la scalabilità), da un altro le complica per quanto riguarda la protezione delle risorse, ma questo problema della sicurezza lo affronteremo a suo tempo.

Nel prossimo post vi presenterò un esempio pratico completo di codice.