Workflow con REST (REpresentational State Transfer)
Pubblicato da Andrea Gumina su 25 Agosto 2008
Jim Webber, nella presentazione “A Couple of Ways to Skin an Internet-Scale Cat” tenuta al Qcon 2008 di Londra, discute, tra le altre cose, come realizzare un workflow con REST (o, meglio, con la sua implementazione più nota: HTTP).
La presentazione mostra la sequenza di richieste e risposte per ordinare, pagare, ottenere caffé e latte da Starbucks. Il workflow così ottenuto rispetta i vincoli che REST impone: in particolare l’interfaccia uniforme – le risorse sono identificate mediante URI, le operazioni possibili sono predeterminate, hanno semantica nota, indipendente dalle risorse, e le rappresentazioni in risposta contengono le possibili transizioni di stato (come link, annotati per indicare la semantica associata).
Il consumatore, quindi, non conosce a priori la sequenza, il servizio è l’unico a conoscerla; ritornando riferimenti (annotati) guida il consumatore. Supposto che le due parti si accordino preliminarmente sulla semantica e sulla “sintassi” di ogni possibile passo, il servizio potrà, in ogni momento, modificarne la sequenza (nell’ordine o nel numero) senza conseguenze per chi la consuma.
Questo approccio sembra meglio applicabile qualora il colloquio si svolga interamente con un’unica “giurisdizione” (entrati in un ufficio e dovendo trattare con un certo numero di impiegati secondo una sequenza non nota a priori, ciascuno di questi, dopo aver svolto il lavoro di propria competenza, indica il collega con cui proseguire) e serva interazione a passi intermedi (così da non poter essere celati dietro un unico punto di ingresso). Qualora il colloquio avvenga con più “giurisdizioni” sembra irrinunciabile, a meno di compromessi, un coordinatore esterno che smisti.
L’accordo, l’associazione e le annotazioni sulla semantica sembrano d’obbligo: con i link si riesce ad esprimere solo l’interrogazione della risorsa (GET con i parametri riportati dal link stesso nella query string); OPTIONS, da solo, potrebbe non tenere la logica di business separata da quella di comunicazione e non essere sufficiente (in base a quale semantica decidere se eseguire una POST, una PUT o una DELETE?).
Qualunque workflow è risolvibile con questo approccio (continuando a soddisfare i vincoli che REST impone)? Lo stato di una risorsa è sempre nella posizione di indicare operazioni da svolgere su un’altra (che non siano d’interrogazione)?
—-><—-
Hai trovato questo post interessante? Segui il feed e commenta!
