REST: risorse "complesse"
Pubblicato da Andrea Gumina su 2 Luglio 2008
La RFC 2396 (URI – Uniform Resource Identifier) definisce “risorsa” una qualunque cosa che abbia un’identità e che – concettualmente – possa corrispondere ad un’entità o un insieme.
E’ un po’ che mi chiedo se “dietro” una risorsa si possa “nascondere” qualcosa di più “complesso” (una serie di passi, ad esempio, una logica applicativa complicata a piacere, ecc.), continuando, però, a soddisfare i vincoli di REST (mi riferisco, sopratutto, all’interfaccia uniforme e alla mancanza di stato).
Stefan Tilkov, autore dell’articolo “Addressing Doubts about REST” (già citato in un articolo precedente “Letture consigliate su REST“), spiega come REST (REpresentational State Transfer) non sia confinato alle sole operazioni CRUD (Create, Read, Update and Delete): una URI tipo http://example.com/calculation?a=2&b=3, infatti, può corrispondere alla somma tra a e b. L’articolo descrive una soluzione in sintonia con REST (implementato con HTTP): una POST che abbia come effetto la creazione della risorsa-risultato e come ritorno la URI corrispondente (da usare con una GET).
Il libro “RESTful Web Services” di Leonard Richardson e Sam Ruby, nella parte dedicata al disegno di risorse, illustra strategie simili.
Quindi dietro una risorsa si può celare qualcosa di più “complesso” di una “semplice” entità. Tale risorsa, però, non coincide con la risorsa-risultato cercata, è il punto di raccolta delle richieste (“RESTful Web Services” lo definisce factory): accoglie i POST (richiesta di creazione, non sicura, non idempotente), crea la risorsa-risultato (o ne accoda la richiesta) e ne ritorna l’URI da usare con una GET (richiesta di informazioni, sicura, idempotente).
Questo, che sicuramente rispetta i vincoli imposti da REST, mi sembra, oltre che macchinoso, richiedere al client una certa “consapevolezza” (che, in taluni casi, potrebbe rafforzare l’accoppiamento): alla POST deve seguire necessariamente una (o più) GET con cui recuperare la risorsa-risultato (o richiederne lo stato di esecuzione – in tal caso il client deve farsi carico anche di una DELETE per eliminare la risorsa temporanea). Conseguenza dell’interfaccia uniforme (i metodi con semantica indipendente dalle risorse sono generici, non specializzati e, talvolta, impongono al client di soddisfare un flusso di lavoro ben preciso) e della mancanza, per alcune situazioni, di soluzioni REST collaudate.
Un codice 201 (“Created”), in risposta alla POST, che oltre alla URI della risorsa creata riportasse la sua rappresentazione, o un codice 303 (“See Other”) che “inviterebbe” ad eseguire “automaticamente” una GET verso la URI ritornata (la risorsa-risposta), potrebbero isolare la logica di business del client dalle logiche del colloquio HTTP; sono soluzioni, comunque, da studiare di volta in volta.
—-><—-
Hai trovato questo post interessante? Segui il feed e commenta!
