Recensione di RESTful Web Services

restful web services
Se le parole web e servizio hanno un qualche significato per voi, dovete leggere
questo libro. Da copertina a copertina.

Sembra una introduzione melodrammatica ma in effetti è la mia conclusione. Leonard Richardson e Sam Ruby hanno fatto un ottimo lavoro mettendo insieme un libro che dà una struttura e una motivazione al termine REST e a tutto ciò che ne concerne.

REST, come sicuramente sapete, è uno stile architetturale per la progettazione di servizi web nel vero senso della parola. A me piace chiamarlo HTTP done right.

Nel 2000 Roy Fielding, uno dei principali autori del protocollo HTTP, pubblicò la sua tesi di dottorato intitolata “Architectural Styles and the Design of Network-based Software Architectures” dando il la a quello stile definito appunto “Representational State Transfer” (REST in breve).

Uno dei concetti fondamentali in questo genere di architetture è quello di risorsa, rappresentata da una URI. Per comunicare con la risorsa (singola o collezione di altre risorse) si usa HTTP. In tal modo attraverso l’uso dei verbi (metodi) HTTP, quali HEAD, GET, POST, PUT e DELETE si può chiedere al server web una rappresentazione o creare risorse aggiuntive. L’altro concetto fondamentale da tenere a mente è che HTTP è prima di tutto un protocollo stateless. Questo significa che ogni richiesta è e deve essere totalmente indipendente dalle precedenti; in tal modo il messaggio della richiesta conterrà tutte le informazioni necessarie affinché il server possa processarlo e fornire una risposta corretta.

Una delle conclusioni a cui si giunge studiando REST e il libro di cui sopra è la semplicità del tutto. Vi è, almeno per quanto mi riguarda, una sensazione di scoperta dell’acqua calda quando ci si rende conto che Fielding prima e il duo Richardson e Ruby poi non fanno altro che spiegare al mondo come avrebbe dovuto essere il web interconnesso prima dell’avvento di quelli che comunemente si chiamano “enterprise web services”.

Il libro è diviso in 12 capitoli più 3 appendici. I primi 3 capitoli spiegano il significato delle parole “web services” mostrando esempi di servizi totalmente RESTful (ossia rispettosi delle linee guida REST), servizi in stile RPC e ibridi REST-RPC. Inoltre guidano il lettore attraverso la scrittura di client per web services ibridi e RESTful. Gli esempi sono in Ruby, Python, Java, C# e PHP. Difficilmente un lettore non conosce sintassi e semantica di almeno uno di questi linguaggi.

I 6 capitoli seguenti sono la vera rivoluzione di concetto. Dopo aver spiegato cosa significa nel dettaglio “architettura orientata alle risorse” gli autori, avvalendosi di un ruolino di marcia, guidano il lettore attraverso la progettazione di un servizio simile a Google Maps prima in sola lettura e poi aggiungendoci anche il supporto in scrittura. Ci tengo a riprodurre questo ruolino per farvi capire la semplicità di questo stile architetturale:

  1. Definire l’insieme dei dati
  2. Suddividere i dati in risorse

    Per ogni tipo di risorsa:

  3. Dare alle risorse una URI

  4. Esporre un sottoinsieme dell’interfaccia uniforme
  5. Progettare le rappresentazioni accettate dal client
  6. Progettare le rappresentazioni servite al client
  7. Integrare questa risorsa con le altre risorse, usando link e form
  8. Considera il tipico ciclo di eventi: cosa dovrebbe succedere?
  9. Considera le condizioni di error: cosa potrebbe andare storto?

Non c’è trucco o inganno. Un’architettura REST è poco più di questo processo.

La seconda sezione del libro continua con un’implementazione di questo servizio usando Ruby On Rails e con un capitolo che spiega quali sono le tecnologie che entrano in gioco nel mondo REST (X(HTML), URI, XML, JSON, Atom…). Il capitolo 8, il penultimo della sezione, è a mio avviso il più importante perché è una collezione di best practice dedicate a chi poi andrà davvero ad implementare un servizio REST. Gli autori spaziano dal concetto di stato, al concetto di connessione, dal design delle risorse all’adattamento dei browser a questa architettura all’annoso problema dei cookie.

Il capitolo 10 mette a confronto le architettura orientate alle risorse e i web service “enterprise” spiegando vantaggi e svantaggi di entrambi gli approcci. L’undicesimo capitolo inserisce Ajax all’interno di una architettura REST. Il capitolo 12 invece presenta tre framework definiti RESTful perché pensati per aiutare lo sviluppatore a creare servizi REST: Ruby On Rails, Django, Restlet.

Il libro si chiude con una serie di puntatori per approfondimento e una lista di web service da cui prendere spunto, una spiegazione dei vari response code di HTTP e sugli header HTTP.

A mio avviso questo è un must have, poi fate vobis 🙂

Comments

  1. Questa recensione non ha fatto altro che aumentare la mia curiosità nei confronti del mondo dei servizi web REST.

    Grazie per l’ottimo servizio che offrite su stacktrace.it, continuate così! Gli articoli sono davvero ottimi e stimolanti!

  2. Grazie Andrea!

  3. Diego Guidi says:

    Anche io ho letto il libro e confermo: must have!

  4. Alan Franzoni says:

    Concordo pienamente: è un testo estremamente valido. L’ho quasi finito di leggere: oltre ad averlo trovato ben scritto, è davvero molto “filosofico” e poco “tecnico”: non indugia su dettagli inutili, va dritto al centro del discorso, e fa vedere come molto spesso le tecniche di progettazione web “convenzionali” siano fonte di problemi che non dovrebbero neppure porsi.

    Lo trovo carente, tuttavia, sul fronte della sicurezza; i webservice stateless si prestano più di altri ad alcune piaghe come l’XSRF; questi problemi andrebbero affrontati fin dall’inizio in maniera radicale. E’ inutile progettare un web service in maniera RESTful se poi qualsiasi script kiddie può fregare ad un utente loggato qualsiasi dato in esso contenuto.

    La strada è quella giusta, in ogni caso!

  5. I libri che impostano una forma mentis e/o una filosofia son sempre i migliori. Gli aspetti tecnici cambiano piu` velocemente 😉

    Direi che non e` un libro che ha a che fare con la security, pero` certo, un accenno sarebbe stato gradito.

    Personalmente credo che uno degli aspetti che vanno migliorati/aggiunti sia l’autenticazione e il concetto di logout. Uno dei motivi per cui alla fine tutti girano intorno alla autenticazione HTTP

  6. Alan Franzoni says:

    Il problema è proprio nell’idea che un libro che parla di webservice non parli di security. Secondo me tutti quanto dovremmo iniziare a porci un po’ di più il problema *dalla radice*: spesso e volentieri un design errato (=insicuro) dalla radice è molto difficile da correggere a posteriori.

    Il secure coding dovrebbe essere una pratica ormai basilare e assodata, anche se, purtroppo, spesso non è così 🙁

  7. Purtroppo, non esiste una vera cultura della security dal day 0, a meno di non avere un esperto di security a 360gradi nel team

  8. Qual’e’ il modo migliore per acquistarlo on line in Italia?
    Da una rapida ricerca mi sembra che l’offerta migliore sia della Hoepli:
    http://www.hoepli.it/libro.asp?ib=9780596529260

  9. Io l’ho preso su Amazon, però direi che un posto vale l’altro. Un’altra libreria online che uso spesso è ibs.it

    ciao!

  10. Mi stavo giusto chiedendo se fosse un libro valido. Bene ora lo inizio subito a leggere! 😀

    Peccato per la pecca della sicurezza, qualcuno ha trovato online qualche aggiunta che possa colmare questa mancanza?

    Sono proprio contento di essermi imbattuto in questo sito (grazie riffraff che ne ha parlato), continuate così! 🙂

  11. Ti ringrazio, avevo cominciato a leggerlo qualche tempo fa su safari (la libreria) ma dopo i primi 3 capitoli mi sembrava dicesse sempre le stesse cose, ma ringrazio moltissimo te per il resoconto, ora lo leggero molto più approfonditamente. Comunque anche DHH consiglia di leggerlo, dovrebbe esserci scritto sulle prime pagine se non sbaglio, ora capisco il perchè!

Policy per i commenti: Apprezzo moltissimo i vostri commenti, critiche incluse. Per evitare spam e troll, e far rimanere il discorso civile, i commenti sono moderati e prontamente approvati poco dopo il loro invio.