Se stai creando un sistema REST, è per definizione senza stato, quindi la sessione non è qualcosa che gestisci direttamente.
Mettendo da parte per il momento, presumo.se intendi solo che le richieste dovrebbero essere autenticate e che vuoi sapere chi l'utente deve autorizzare qualsiasi azione stia prendendo.
In tal caso, hai tre approcci generali da prendere.
1) mantenere una qualche forma di archivio di sessioni in memoria con un cookie (o un altro segreto, come un token URL) passato per fungere da chiave per la richiesta. Ciò si ridimensiona in modo inadeguato, poiché ogni operatore nel cluster ha il proprio spazio di memoria.
2) Ricerca DB dell'utente in ogni richiesta, passando le credenziali o (di nuovo) qualche forma di token di sessione ogni volta. Questo ha il vantaggio che tutti i nodi front-end della tua app possono condividere il DB e sono tutti aggiornati sui diritti degli utenti.
3) Una forma di token crittografato che include qualsiasi informazione utente necessaria per creare l'oggetto Utente. Lo standard più comune per questo è il token Web JSON, ma anche altri possono funzionare. Questo ha il vantaggio di essere molto scalabile e non richiede viaggi DB su ogni richiesta, ma aggiunge la sfida dell'invalidazione del token (ad es. Al logout o quando un utente cambia i diritti).
Quindi tutti e tre stanno bene a seconda di ciò che ti serve. Alcune app usano anche un ibrido (ad esempio # 2 con # 1 come cache per migliorare le prestazioni), ma aggiungono anche complessità e portano avanti nuove cose da considerare (come l'invalidazione degli elementi della cache).
Infine, alcune app adottano un approccio eterogeneo al database, utilizzando un negozio di documenti come Mongo per i loro oggetti di business principali e un negozio di valore chiave veloce come Redis o memcached per cose che capitano a ogni richiesta (come l'autenticazione dell'utente).