Servizio stateless

Question

Servizio stateless

#1 da (1 voti)
#2 da (0 voti)

1

Attualmente sto lavorando a un progetto di un giocatore. Senza entrare nei dettagli ho due livelli principali 1. Servizi di riproduzione 2. Interfaccia utente. I servizi di riproduzione sono costituiti principalmente dal servizio Player e dal servizio browser. Comunicano tramite API REST. L'interfaccia utente si abbona a vari servizi. Voglio mantenere i servizi quanto meno stateless possibile.

Sono un po 'confuso su come mantenere i servizi senza stato. Per quanto riguarda il browser è semplice. Ottengo un percorso per navigare, recupero i risultati e li pubblicano e il servizio browser è di nuovo senza stato.

Tuttavia, non capisco come posso rendere il giocatore apolide! Prendiamo i casi d'uso concreti: varie operazioni come la riproduzione, la ripresa, la pausa ecc. Possono essere messe in atto solo se il giocatore ha un certo stato. Ad esempio, non è possibile avviare la riproduzione se prima non è stata caricata alcuna traccia. Allo stesso modo, l'interruzione ha senso se stiamo già giocando.

È responsabilità dei clienti cercare gli stati come sono iscritti al giocatore e se il giocatore non è nello stato giusto allora devono prima portarlo nello stato in cui una determinata operazione ha senso?

design-patterns rest services

posta user2219907 30.06.2018 - 11:15

fonte

2 risposte

Leggi altre domande sui tag design-patterns rest services

Come accedere all'accesso ai dati su un server con periodi di inattività di grandi dimensioni Architettura per la comunicazione tra più sistemi di back-end e dispositivi IoT tramite WebSockets

score 1 · Answer 1

Un punto sul termine 'apolide' che può aiutare la tua comprensione è che nessun servizio utile è 'senza stato' nel senso di avere o operare su nessuno stato. Si tratta di dove si memorizza lo stato. Il servizio stateless significa semplicemente che lo stato non è memorizzato nel servizio stesso.

Per gran parte di ciò che hai detto, questo è semplice da ottenere in molti modi. Uno è di prendere tutto lo stato e comprimerlo e codificarlo (ad esempio serializzare come json e base64). Quindi lo si restituisce al client e il client deve passarlo al servizio (come argomento) su ogni chiamata.

Quindi il tuo servizio non mantiene nessuno stato - il client web (e i canali di comunicazione) lo mantengono.

Una semplice variazione su questo (se lo stato è grande) - è quello di memorizzare lo stato in un database. È simile alla consegna dei dati al client Web, ma si è tornati al client Web un 'ID riga' dal database e si è scaricato lo 'stato' dal database in ogni chiamata al servizio web.

Per la riproduzione audio, lo stato è costituito da "dove sei nell'audio" e da altre cose simili. QUELLI sono abbastanza piccoli da poter usare l'approccio convert-to-json e base-64-encode (specialmente se si aggiunge la compressione). Ma i veri "file audio" sono relativamente grandi. Quindi devi imbrogliare un po '. Mantenere una "cache" di file audio in memoria. In questo modo si sta ingannando leggermente, poiché la cache di memoria in-memory dell'audio è, in un certo senso, uno stato. ma il suo stato non essenziale (se hai ucciso il processo e riavviato - funzionerebbe ancora - solo più lentamente)

score 0 · Answer 2

Come ho capito, qualsiasi operazione verrà avviata dall'applicazione client. Pertanto, diventa obbligatorio per l'applicazione client assicurare che il lettore sia nello stato appropriato. Questo per mantenere l'applicazione client senza stato.