REST è un acronimo introdotto nel 2000 da Roy Fielding, uno dei principali autori del protocollo HTTP, che identifica uno stile di architettura per sistemi distribuiti (come il World Wide Web) incentrato sul concetto di risorsa.
Una risorsa è una qualsiasi entità identificabile (univocamente) da un’URL, manipolabile attraverso uno dei 4 verbi dell’http (get, post, put, delete) e indipendente dalla sua rappresentazione. Consideriamo ad esempio la risorsa identificata dall’URL:
http://www.ateapick.com/people/filippo
Attraverso i 4 verbi dell’HTTP posso manipolare (CRUD) la risorsa secondo le seguenti convenzioni:
POST http://www.ateapick.com/people/filippo (C) GET http://www.ateapick.com/people/filippo (R) PUT http://www.ateapick.com/people/filippo (U) DELETE http://www.ateapick.com/people/filippo (D)
Posso inoltre ottenere diverse rappresentazioni della stessa risorsa discriminando la richiesta tramite il mime-type:
GET http://www.ateapick.com/people/filippo (html) GET http://www.ateapick.com/people/filippo.xml GET http://www.ateapick.com/people/filippo.rss GET http://www.ateapick.com/people/filippo.iphone GET http://www.ateapick.com/people/filippo.wii
Rails 1.2 ha introdotto il supporto allo sviluppo REST attraverso un sistema di routing che tiene in considerazione il verbo HTTP utilizzato nella richiesta dell’URL. Le diverse rappresentazioni di una risorsa si possono invece ottenere utilizzando l’instance method respond_to di ActionController::MimeResponds.
Con il rilascio di Rails 2.0 il paradigma REST ha assunto un ruolo ancor più importante nel framework: chiari segnali sono il nuovo scaffolding e il nuovo modo di nominare i file della view che esplicita la creazione di diverse rappresentazioni basate sui mime-type.
Esistono molti documenti che trattano in maniera approfondita l’argomento. Un’ottima guida introduttiva sullo sviluppo RESTful in Rails può essere scaricata a questo indirizzo. Da un po’ di tempo ormai ho fatto mio questo stile di programmazione e, una volta superate le prime difficoltà di “ambientazione”, ho cominciato ad assaporarne tutti i vantaggi: oggi considero le linee guida scelte per il rilascio di Rails2 una consacrazione della qualità e della lungimiranza di questo framework.
Oltre a veicolare lo sviluppo di applicazioni secondo il pattern MVC, il RESTful Rails impone un’ulteriore disciplina nella codifica che garantisce maggiore compattezza, migliore leggibilità, “pretty-urling” e semplicità nella costruzione di API. Pensare ad un’applicazione orientata al CRUD di risorse inizialmente può destare delle perplessità:
“non è un approccio limitato? In una webapp molto spesso ho bisogno di altre azioni rispetto alla semplice creazione, visualizzazione, modifica o cancellazione di una risorsa…”
In realtà dipende da come si interpreta l’applicazione stessa. Un’azione molto comune come la login da parte di un utente, ad esempio, rientra perfettamente nell’approccio REST se pensata piuttosto come la creazione di una sessione; specularmente la logout corrisponde alla distruzione di una sessione; in definitiva il concetto di risorsa è talmente generico che con un minimo di sforzo di astrazione può essere adattato a qualsiasi modello.
Riguardo alla lungimiranza, l’impronta RESTful così marcata del nuovo Rails pone ancor più il framework come scelta azzeccata per chi vuol fare web 2.0 e per chi vuol seguire la cordata di progetti che rappresentano i primi passi verso la costruzione del cosiddetto web semantico. Mi riferisco a progetti come OpenID, un network distribuito e decentralizzato, nel quale la tua identità è un URL e può essere verificata da qualunque server supporti questo protocollo, o come Gravatar secondo il quale è il tuo avatar ad essere identificato da un’URL sull’intero web.
Se poi consideriamo anche le relazioni tra le risorse descritte attraverso XFN e FOAF entriamo nel vasto campo delle Reti Sociali con un’apertura tale per cui perfino Google si accorgerà delle nostre killer webapp… ;-)
