Stato REST persistente sul client senza cookie

C'è lo storage locale HTML5, che ti consente di conservare i dati senza che questo contamini le richieste HTTP che fai. È destinato esattamente a questo caso d'uso: applicazioni Javascript complesse che vogliono memorizzare informazioni persistenti localmente.

link

Si noti che REST non significa escludere tutti gli stati dal server, a volte si desidera sinceramente aggiornare le cose; specialmente nell'esempio del "biglietto aereo" potresti voler creare esplicitamente un oggetto "prenotazione" prima del pagamento con un POST che restituisce un URL per la prenotazione. Il client si blocca quindi sull'URL, ma l'oggetto sul lato server esiste per impedire la prenotazione dello stesso posto due volte.

Il punto che Roy Fielding fa sui cookie si riferisce all'invio di questi cookie al server e al mantenimento dello stato sul server in base a quei cookie. L'utilizzo di un cookie esclusivamente lato client per memorizzare lo stato per qualsiasi periodo di tempo non viola REST e in realtà non riguarda affatto il lato server.

EDIT: È possibile memorizzare un cookie su un percorso che non viene utilizzato dal server. In questo modo puoi accedervi dal tuo javascript, ma non verrà mai inviato.

Non è necessario utilizzare i cookie, ma se si dispone di risorse protette (ad es. il mio carrello anziché il carrello), allora è necessario un modo per rilevare quale richiesta corrisponde a chi di noi. Di solito, tale id è conservato in un cookie poiché il rilevamento viene eseguito sul server tramite costosi meccanismi di autorizzazione che si desidera memorizzare temporaneamente e ripetere ogni richiesta.

logicamente non c'è nulla che ti impedisca di eseguire l'autenticazione su ogni richiesta. (eccetto che nel mondo reale non lo farai a meno che tu non abbia, ad esempio, certificati client che dimostrano la tua identità al server)

Immagino che potresti utilizzare un identificatore univoco che è noto al client e utilizzarlo come associazione tra client e ID utente protetto dopo l'accesso, ma sono difficili da trovare e mantenere la sicurezza.

È possibile utilizzare i cookie per mantenere lo stato del client, poiché si tratta di un meccanismo di archiviazione lato client. Puoi utilizzare altri meccanismi di archiviazione lato client, ad esempio websql o localstorage.

L'unico problema con i cookie, i cookie di sessione stanno violando il vincolo di apolidia. Quindi, a meno che non usi i cookie di sessione, sei a posto. Dovresti chiederti cosa succederebbe quando il server si riavvia. Nel caso dei cookie di sessione, la sessione verrà persa. Nel caso di cookie normali, non accade nulla di rilevante, le tue richieste verranno soddisfatte allo stesso modo di prima.

Penso che quando il server scrive i cookie che è una zona grigia, specialmente se stiamo parlando di cookie solo HTTP (che non sono accessibili nel browser javascript). In questo caso il servizio modifica direttamente lo stato del client. Potremmo argomentare che le intestazioni dei cookie set sono parte della rappresentazione, ma questa è una mezza verità, penso. Se l'API REST ha un dominio diverso da quello del client, quindi imposta i cookie solo sul dominio client e accedi ai loro contenuti, ad esempio con javascript sul lato client, se stiamo parlando di browser.

Non so se la cache e i cookie siano in conflitto tra loro. Non ricordo un problema del genere.

Dovresti utilizzare l'intestazione Autorizzazione invece del cookie, ma penso che non sia una tragedia se imposti il nome utente e la password in un'intestazione solo HTTP. Oppure imposti un cookie persistente con qualche hash (se è registrato sul server come risorsa per un lungo periodo). Penso che sia ancora più sicuro della memorizzazione di questi dati, ad esempio nello spazio locale.