Un servizio dovrebbe utilizzare le informazioni sulla sessione?

Esistono diverse filosofie, ma dipende molto dal contesto e dalle esigenze del tuo lavoro. Se sono richieste più connessioni asincrone per richieste di servizi diverse per condividere lo stato di cui il client non dovrebbe essere a conoscenza, sono disponibili alcune opzioni oltre a un qualche tipo di gestione delle sessioni (sia built-in che personali basate su token di sicurezza o altri meccanismi di identificazione) ). In generale, tuttavia, le sessioni non sono necessarie quasi con la stessa frequenza con cui vengono utilizzate e spesso tendono a portare a complicazioni in seguito. La sessione è volatile, solitamente non intrinsecamente thread-safe, e legata in primo luogo a dettagli arbitrari del client (cookie, IP, ecc.) Quando non si controlla il client, le sessioni possono essere inaffidabili. Potrei, ad esempio, implementare un client REST GET solo con nient'altro che richieste HTTP non elaborate (che qualcun altro ha effettivamente fatto prima). Di conseguenza, i dettagli di implementazione comuni come la persistenza dei cookie diventano un requisito del tuo servizio; questo non è raro, ma i requisiti meno inutili che usi sono più affidabili delle esperienze dei clienti.

In generale, quando possibile, lascia che lo stato sia direttamente associato alle singole richieste. Ciò consente ai singoli clienti una maggiore flessibilità poiché il design si spiega da solo e non dipende da funzionalità nascoste che il cliente non sarà in grado di prevedere. Inoltre, consente in modo più naturale più connessioni simultanee dallo stesso client di avere scopi e stati completamente diversi. Diciamo che il loro sito web consente i singoli accessi degli utenti e fanno chiamate al tuo servizio (API) specifiche per i singoli utenti; se più utenti utilizzano l'app nello stesso momento, non si vuole forzarli in una singola sessione se possono semplicemente fornire un token con ogni richiesta o qualcosa di simile. Può essere facile perdere traccia delle mutazioni di stato quando si trovano in uno spazio di sfondo invisibile e, anche se il servizio è semplice all'inizio, le future aggiunte potrebbero non rendersi conto che qualcosa stava usando la sessione in un certo modo, ecc. Ecc. Davvero, questo è molto simile alle pagine web. Se ti affidi alla sessione per le operazioni specifiche della pagina, l'utente non può utilizzare più schede in quanto inquinerà lo stato, mentre l'archiviazione dei dati di stato in un campo modulo nascosto o stringa di query consente a ciascuna scheda di mantenere il proprio stato.

Generalità a parte, ci sono certamente circostanze che lo richiedono. Gli ambienti di elaborazione distribuiti come WCF e altri livelli di sistema RPC che sfruttano i servizi Web utilizzano il rilevamento delle istanze del servizio, i campi interni permanenti, il contesto condiviso, ecc. Queste caratteristiche utilizzano Session o almeno funzionano in modo molto simile da una prospettiva astratta. Alcune persone non sono d'accordo con questi metodi, ma lo strumento giusto per il lavoro giusto dovrebbe sempre essere l'obiettivo.

Nel tuo caso specifico , sembra che tu stia davvero solo cercando di condividere lo stato di autenticazione tra il browser e le richieste di backend asincrone. Lo stato di autenticazione è spesso sostenibile nei servizi web. In particolare per l'autenticazione, sembra che dovresti utilizzare i controlli di sicurezza anche se hai ricevuto un ID utente (dal momento che non dovrebbe semplicemente distribuire tali informazioni a nessuno) e dal momento che hai già i dati suona perfettamente sicuro (meno errori / incline incline, dal momento che non si dà loro la possibilità di dirvi quale utente utilizzare). In alternativa, è possibile ricevere il parametro in modo specifico per verificare che non stiano interferendo con le richieste, anche se ciò va solo oltre. Ancora una volta, proprio come una pagina web, la condivisione dell'autenticazione tra le schede del browser non è rara, anche se le schede hanno pagine molto diverse, ma quelle pagine (o middleware associato) sono ancora responsabili della determinazione di ciò che l'utente può vedere e l'utente ha il diritto di essere su qualsiasi pagina specifica.

tl; dr - Ci sono meriti per entrambi gli approcci in questo contesto, incluso l'uso di entrambi in tandem. L'autenticazione è comunemente condivisa in servizi Web di diversa varietà. Se queste sono per le richieste Ajax, allora è particolarmente comune. In generale, tuttavia, utilizzare lo stato condiviso di sfondo solo quando necessario (in modo simile alle pagine Web). Lo stesso tipo di cura va nel decidere cosa sarà statico, filo-statico, ecc. Ricorda i bambini: solo tu puoi prevenire gli incendi boschivi. BACIO

Il tuo servizio dovrebbe ottenere tutte le informazioni di cui ha bisogno per svolgere il proprio lavoro nei suoi parametri. Se il tuo servizio chiama qualcos'altro per ottenere un ID utente o qualsiasi altra cosa, deve generare il suo oggetto di ritorno che è un progetto scadente.

Va bene per un servizio utilizzare un altro servizio per farlo funzionare. Non è un problema. Tuttavia, se il tuo metodo PostService.FindPosts () ha bisogno di un ID utente, non passarlo a SecurityService, passalo a userId. In effetti, potresti chiamarlo FindPostsByUserId () solo per essere più esplicito.

Ora potrebbe essere necessario ottenere l'ID utente da un SecurityService inserito nel PostsService, ma questo è un altro problema.