Memorizzazione dei dati di sessione sul lato client o server

Question

Memorizzazione dei dati di sessione sul lato client o server

#1 da (0 voti)

0

Ho un'applicazione Android che comunica con il server usando REST. Durante il flusso, il client (Android) di solito invia 3 richieste separate al server con dati diversi.

Alcuni dei dati inviati durante la prima richiesta vengono utilizzati anche durante la terza richiesta. Ovviamente, non vogliamo chiedere all'utente di inserire due volte gli stessi dati, quindi pensiamo di memorizzare i dati in sessione. Creiamo la sessione utilizzando i token Web JSON.

Quindi, sembra che abbiamo 2 opzioni:

Memorizza i dati della sessione sul lato client (Android) e invia nuovamente i dati nella terza richiesta
Archivia i dati di sessione sul lato server nel database temporaneo e utilizza i dati da lì quando necessario (nella terza richiesta)

Da quello che vedo, nel primo approccio invieremo più dati nella terza richiesta, ma sul lato server non dobbiamo fare una chiamata al database per memorizzare i dati nella prima richiesta e recuperare più tardi nel 3 °.

Sembra che l'invio di un po 'più di dati (nel nostro caso si tratta di una stringa di 10-20 caratteri) è meno costoso, quindi passa al DB due volte (prima per memorizzare i dati e successivamente per recuperare i dati)

Qual è la migliore pratica qui? Dipende dalla quantità di dati? Ci sono più pro e contro? Ci sono altre soluzioni migliori?

Inoltre, sembra che la memorizzazione dei dati sul lato server sia in conflitto con il principio Stateless del REST

performance rest android

posta user3362334 19.12.2018 - 20:22

fonte

1 risposta

Leggi altre domande sui tag performance rest android

Avvolgimento di un'API di terze parti: connessioni Pattern Gateway Cosa devo includere nel documento di progettazione OOP?

score 0 · Answer 1

REST

Se si dispone di un server RESTful, tutti i dati necessari per un'interazione devono essere trasferiti al server come parte della richiesta. Ciò significa che l'applicazione deve mantenere lo stato per la conversazione.

Gettoni

Detto questo, potrebbe essere più sensato per la prima richiesta di ricevere token nella sua risposta, e quindi avere quel token restituito con la richiesta successiva. Il token deve essere crittografato / firmato / espirabile per ridurre al minimo la stanza in cui i cattivi attori possono trarre vantaggio dal server. Non passare mai dati sensibili (anche crittografati).

architecting

Se sei preoccupato per la velocità e sai che le richieste 1, 2 e 3 avvengono in sequenza (sempre), perché non offrire una singola richiesta per ottenere tutto quanto sopra.

Cache RAM

Un Database può facilmente avere una cache RAM avvolta attorno ad esso. Le voci più recenti possono essere aggiunte, soprattutto considerando che saranno necessarie in due richieste di tempo.

Server pieno di stato

Se il sovraccarico della rete e l'accesso al database sono veramente onerosi, o la tolleranza di latenza / jitter per l'elaborazione delle richieste è stretta, un server dedicato allo stato è la soluzione.

Utilizza un Websocket o un'altra struttura di comunicazione punto-punto e tieni un residente dedicato alla memoria di processo che contiene tutte le informazioni rilevanti per la manutenzione di questo client.

Si noti che questo non è molto scalabile ed è difficile rendere tollerante ai guasti.