I cookie devono essere utilizzati in un'API RESTful?

Un servizio ReSTful ideale consente ai client (che potrebbero non essere nel browser) di eseguire qualsiasi attività necessaria in una richiesta ; perché lo stato completo necessario per farlo è detenuto dal client, non dal server. Dal momento che il client ha il pieno controllo dello stato, può creare lo stato da solo (se questo è legittimo) e parlare solo con l'API per "fare".

Richiedere i cookie può renderlo difficile. Per i clienti oltre ai browser, la gestione dei cookie è un grosso inconveniente rispetto ai parametri di query, alle intestazioni di richiesta semplice o al corpo della richiesta. D'altra parte, nel browser, l'uso dei cookie può rendere molte cose molto più semplici.

Quindi un'API potrebbe prima cercare nell'intestazione Authorization i dati di autenticazione di cui ha bisogno, dal momento che probabilmente è il posto in cui i client non browser preferiscono inserirla, ma per semplificare e ottimizzare i client basati su browser, potrebbe anche controlla un cookie di sessione per l'accesso lato server, ma solo se mancava l'intestazione Authorization regolare.

Un altro esempio potrebbe essere una richiesta complessa che normalmente richiede molti parametri impostati. Un client non interattivo non avrebbe problemi a bloccare tutti questi dati in una richiesta, ma un'interfaccia basata su un modulo HTML potrebbe preferire suddividere la richiesta in più pagine (qualcosa come un insieme di pagine 'wizard') in modo che gli utenti non vengano presentati con opzioni che non sono applicabili in base alle selezioni precedenti. Tutte le pagine intermedie potrebbero memorizzare i valori nei cookie lato client, in modo che solo l'ultima pagina, in cui l'utente effettivamente la richiesta, abbia alcun effetto collaterale sul server. L'API potrebbe cercare gli attributi necessari nel corpo della richiesta e tornare a guardare i cookie se i parametri necessari non erano presenti.

Modifica: in RE al commento di @ Konrad qui sotto:

Tokens in comparison are harder to implement especially because you can't easily invalidate the token without storing them somewhere.

er ... stai convalidando i cookie sul lato server, giusto? Solo perché hai detto al browser di scartare un cookie dopo 24 ore, non significa che lo farà. Questo cookie potrebbe essere salvato da un utente altamente tecnico e riutilizzato molto tempo dopo che è "scaduto".

Se non si desidera memorizzare i dati di sessione sul lato server, è necessario memorizzarli nel token (cookie o altro). Un token auth autonomo viene talvolta chiamato Macaroon. Come viene passato tra client e server (sia da cookie, come extra intestazioni, o nell'entità richiesta stessa) è totalmente indipendente dal meccanismo di autenticazione stesso.

Sì e No: dipende da come lo si utilizza.

Cookie se utilizzati per mantenere lo stato del client sul client, per il client, del client e dal client, quindi sono riposanti.

Se stai memorizzando lo stato del server nel cookie, in pratica stai semplicemente spostando il carico sul client, che non è riposante.

Quindi quali sono alcuni esempi?

riposante:

• Dettagli dell'autenticazione o "sono registrati" per materiale
• ultima pagina visualizzata o luogo nell'applicazione ecc.

Not Restful:

• Archiviazione delle informazioni sulla sessione

La tranquillità viene dall'apolidia - del server. I client possono mantenere lo stato dell'applicazione e inviarlo al server per dire dove sono in modo che il server possa decidere dove andare da lì. Fondamentalmente, le sessioni / stati hanno bisogno di dati storici e dipendono dalle richieste passate, per così dire, le applicazioni restful non lo sono (non è fattibile avere un'applicazione restful al 100% se si ha una schermata di accesso:)

Si possono usare i cookie. REST li consente.

REST richiede che tutte le informazioni sulla sessione vengano archiviate sul lato client, ma quando si tratta di autenticazione, alcune informazioni devono rimanere sul lato server per motivi di sicurezza.

Da uno dei miei post sul mio blog, c'è un accordo generale che i dati di autenticazione sono considerati fuori portata rispetto a REST. Quindi, è ok per i server mantenere alcuni di questi dati di sessione dalla loro parte.