Crea una risorsa complessa atomicamente con oggetti nidificati tramite REST

1

Sfondo: C'è un client UI e un servizio web REST.

Il modulo dell'interfaccia utente consente di creare un oggetto complesso. L'oggetto complesso è composto da tipi primitivi (stringa, numeri interi, ...) e tipi nidificati (tipi di riferimento). Ciascuno dei tipi nidificati è accessibile tramite un endpoint di risorsa REST e l'oggetto complesso.

L'utente può creare un oggetto complesso nel modulo dell'interfaccia utente, e per ciascuno degli oggetti nidificati può collegarlo con un nuovo oggetto nidificato (crearlo sullo stesso schermo del modulo) o < em> collegalo con l'oggetto nidificato esistente basato sull'ID .

  • Tutti gli oggetti sono persistenti nel DB. Ciascuno nella sua tabella e le sue relazioni sono definite (ORM - EF).

Il problema: Il modulo invia l'operazione dovrebbe essere atomico. Se l'utente invia il modulo, è un'operazione tutto o niente. È anche importante notare che: Se un oggetto complesso è stato collegato con un nuovo tipo annidato e qualcosa è andato storto durante la creazione dell'oggetto, anche il nuovo tipo annidato non verrà creato! .

Sono arrivato con poche opzioni per risolverlo, ma mi piacerebbe sapere se esiste un approccio migliore. L'unica differenza tra queste opzioni è la struttura del modello HTTP BODY

Approcci della soluzione:

  1. Crea un nuovo oggetto complesso tramite un'operazione POST contro la risorsa oggetto complessa, con il corpo contenente l'intero modello di oggetto. In tal caso, il client (UI) dovrebbe inviare gli interi oggetti nidificati con il loro id anche se già esistono.

  2. Crea un nuovo oggetto complesso tramite un'operazione POST contro la risorsa oggetto complessa. Il corpo conterrà solo identificatori come riferimento agli oggetti nidificati. In tal caso, è necessario creare una transazione, poiché un utente non riesce a creare l'oggetto complesso e dovremmo eseguire il rollback degli oggetti nidificati.

  3. Un mix di (1), (2), il corpo conterrà id e tipi nidificati di oggetti reali, e l'utente popolerà ciascuno in base alle esigenze richieste.

Ci sono degli svantaggi per ciascuna opzione:

Con l'opzione 3, sarà complicato convalidare e mantenere la creazione dell'oggetto.

L'opzione 2 riguarda la gestione della transazione distribuita.

L'opzione 1 sembra l'approccio preferito. Tuttavia, lo svantaggio evidente qui è che devi sempre inviare l'intero oggetto (anche se l'oggetto è già stato creato, dovrai prima recuperarlo tramite l'operazione GET e poi inviarlo successivamente sull'operazione POST).

Quale pensi sia la soluzione giusta qui?

Sto utilizzando Asp.Net WebApi come WebService Framework, Entity Framework come Database Layer e React-JS sul frontend.

    
posta Omri L 26.02.2018 - 11:24
fonte

0 risposte

Leggi altre domande sui tag