Come si implementa un blocco ottimistico a grana grossa in REST?

Question

Ho implementato il blocco ottimistico per le mie risorse REST che hanno un mapping 1-a-1 alle tabelle di database restituendo un numero di versione che era nel GET indietro fino alla chiamata PUT. Se il numero di versione è cambiato nel database tra il momento in cui ho eseguito GET e PUT, si è verificata un'eccezione di blocco ottimistico. Design abbastanza semplice.

Ora, come faccio a fare lo stesso per le risorse composite REST che si associano a più tabelle di database? Mi piacerebbe non dover passare indietro più campi di versione (uno per ogni tabella di dati che si riferisce alla risorsa composita). Un esempio semplicistico di una risorsa composita sarebbe/FooBar dove/Foo e/Bar sono risorse non composite.

praticamente sto cercando un esempio di Implementazione REST del modello di grana grossa di chiusura di Fowler: http://martinfowler.com/eaaCatalog/coarseGrainedLock.html

Answer 1

Questo è ciò che il ETag header è stato progettato per. Un modo molto comune per implementarlo è produrre il payload della risposta, crearne un hash (non deve essere sicuro, solo una collisione bassa), e quindi usare quell'hash come valore di ETag. Si noti che questo approccio ignora il numero di fonti coinvolte nella produzione della risposta.

Il client invia quindi l'ETag ricevuto in un'intestazione If-Match, che il server può utilizzare per verificare la freschezza della richiesta.