Sto provando a progettare un RESTful (o forse dovrei dire RESTlike, dal momento che non sto progettando un'API pienamente RESTful, ad esempio non guidata dall'ipertesto) come parte di un refactoring di un esistente "take-a- numero "sistema di gestione di accodamento .
I concetti di base e il flusso di lavoro sono:
-
Un determinato sito (posizione) può proporre diversi servizi e avere più desk. Ogni desk può fornire uno o più servizi sul sito. (ad esempio in una banca, puoi avere un ufficio informazioni, scrivanie per operazioni comuni come un deposito e scrivanie dove puoi sederti per parlare con un consulente per cose più complesse, ad esempio aprire un nuovo account o richiedere un mutuo)
-
Quando entra nell'edificio, un cliente stampa un biglietto selezionando un servizio su uno schermo tattile . (ad esempio "Apri un nuovo account"). D'ora in poi il ticket verrà tracciato nello stato interno del server.
-
Il ticket rimane in coda per un po '
-
L'operatore della scrivania chiama il prossimo cliente facendo clic su un pulsante. Il sistema determina quale è il prossimo biglietto adatto per la scrivania (dato che non tutti gli sportelli forniscono gli stessi servizi)
-
Una volta che il ticket è stato chiamato su una scrivania, viene visualizzato un evento e un sistema di visualizzazione mostra il numero del ticket insieme al desk dove il cliente dovrebbe andare
-
Quando il cliente arriva alla scrivania , l'operatore fa clic su un altro pulsante, quindi segnala l'inizio della fornitura effettiva del servizio
-
Una volta che il servizio è stato fornito e il cliente lascia , l'operatore della scrivania fa clic su un altro pulsante, il ticket viene archiviato e il banco torna libero. Fino a quando l'operatore non chiama il prossimo ticket.
Esiste un server centrale e 2 tipi di app client: il terminale di distribuzione dei biglietti e il client della GUI della scrivania.
Quindi, in termini di risorse REST, una delle risorse principali è il ticket. Innanzitutto, viene creato un nuovo ticket (POST) e viene attribuito un numero. È facile.
Ma allora non so come modellare le transizioni allo stato del ticket che sono avviate dal client desk, dal momento che non sono solo aggiornamenti del ticket ma attivano la logica di business che viene eseguita sul server e ha side- effetti non solo sul biglietto:
- Chiama il prossimo ticket (provoca una modifica dello stato sul server, il ticket viene prelevato dalla coda, associato al desk che lo ha chiamato e contrassegnato come "chiamato")
- Segnala al server che il cliente è arrivato alla scrivania (provoca una modifica dello stato sul server, il ticket è contrassegnato come "in fase di pubblicazione", ancora associato alla scrivania)
- Segnala il server che il cliente ha lasciato (causa una modifica sul server, il ticket è separato dalla scrivania, contrassegnato come "servito", inserito in una raccolta di tutti i ticket serviti, e una voce di registro è scritta nel DB)
- Segnala al server che il cliente non è arrivato ( no show ) e il ticket viene annullato (provoca una modifica sul server, il ticket viene separato dalla scrivania, inserito in una raccolta di tutti i biglietti annullati, contrassegnati come "non serviti" e una voce di registro viene scritta nel DB)
Etc.
Tutte queste operazioni dovrebbero essere eseguite anche in modo atomico e in modo sincrono.
Si adattano bene alle "azioni", ad esempio RPC, e questo è il modo in cui è stato implementato nelle versioni precedenti del sistema (ovvero le chiamate RMI). Ad esempio, il desk può "chiamare il prossimo ticket" (un'azione) e recupera il prossimo ticket corrispondente.
Come modellarli in modo RESTful?
Inoltre, ne vale la pena, o dovrei semplicemente essere un po 'flessibile su RESTfulness e modellarlo come "azioni" o qualcosa di simile (quindi in pratica RPC su HTTP)?
Grazie per i tuoi pensieri!