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.