Penso che potresti avere un processo utente per la mancata corrispondenza dell'implementazione qui.
Primo: un utente vuole onestamente eseguire simultaneamente più modifiche a un file?
Un rinominare (che può includere o non includere un cambio di percorso?), Il cambio di proprietà e forse la modifica del contenuto del file (per ragioni di discussione) sembrano azioni separate.
Prendiamo il caso in cui la risposta è "sì": i tuoi utenti vogliono davvero apportare queste modifiche contemporaneamente.
In questo caso, raccomando vivamente contro qualsiasi implementazione che invia più eventi - RenameFileCommand , MoveFileCommand , ChangeOwnerCommand - per rappresentare questo intento utente singolo .
Perché? Perché gli eventi possono fallire. Forse è estremamente raro, ma il tuo utente ha presentato un'operazione che sembrava atomica: se uno solo degli eventi downstream ha esito negativo, lo stato dell'applicazione non è più valido.
Stai anche invitando i rischi della corsa su una risorsa che è chiaramente condivisa tra ognuno dei gestori di eventi. Dovrai scrivere "ChangeOwnerCommand" in modo che il nome del file e il percorso del file non siano importanti, perché potrebbero non essere aggiornati al momento della ricezione del comando.
Quando si implementa un sistema restful gestito da un evento con spostamento e ridenominazione dei file, preferisco garantire la coerenza utilizzando qualcosa come un sistema eTag - assicurarsi che la versione della risorsa che si sta modificando sia quella che l'utente ha recuperato l'ultima volta, e fallire se è stato modificato da allora. Ma se stai inviando più comandi per questa singola operazione utente, dovrai incrementare la tua versione della risorsa dopo ogni comando, quindi non hai modo di sapere che la risorsa che l'utente sta modificando è la stessa versione della risorsa che hanno letto l'ultima volta .
Ciò che intendo è - cosa succede se qualcun altro esegue un'altra operazione sul file quasi alla stessa ora. I 6 comandi potrebbero accumularsi in qualsiasi ordine. Se avessimo solo 2 comandi atomici, il precedente comando potrebbe avere successo e il successivo comando potrebbe fallire "la risorsa è stata modificata dall'ultimo recupero". Ma non c'è protezione contro questo quando i comandi non sono atomici, quindi la coerenza del sistema è violata.
È interessante notare che c'è un movimento verso qualcosa come l'architettura basata su eventi in REST, chiamato "Rest without PUT", raccomandato in Radar della tecnologia Thoughtworks, gennaio 2015 . C'è un blog considerevolmente più lungo su Riposo senza PUT qui .
Essenzialmente, l'idea è che POST, PUT, DELETE e GET vanno bene per le piccole applicazioni, ma quando hai bisogno di iniziare a pensare a come put e post e delete potrebbero essere interpretati dall'altra parte, introduci l'accoppiamento. (ad esempio "quando CANCELLO la risorsa associata al mio conto bancario, l'account deve essere chiuso") e la soluzione proposta è quella di trattare REST in un modo più elaborato da un evento. Ad esempio, consente a POST l'intento dell'utente come singola risorsa evento.
L'altro caso è più semplice. Se i tuoi utenti non vogliono fare tutte quelle operazioni contemporaneamente, non lasciarle. POST un evento per ogni intento dell'utente. Ora puoi usare il controllo di versione di etag sulle tue risorse.
Come per le altre applicazioni che utilizzano un'API molto diversa per le tue risorse. Puzza di guai. Puoi costruire una facciata della vecchia API sopra l'API RESTful e indirizzarla alla facciata? esporre un servizio che esegue più aggiornamenti a un file in sequenza tramite il server REST?
Se non costruisci l'interfaccia RESTful sulla vecchia soluzione, né costruisci una facciata della vecchia interfaccia sopra la soluzione REST e tenti di mantenere entrambe le API puntate su una risorsa dati condivisa, avvertirai grossi grattacapi .