Le sessioni sul lato server violano REST?

Direi di sì, lo stato della sessione non rende RESTful un'app RESTful. Esempio banale, mia sorella si iscrive al Wall Street Journal. Su base regolare, leggerà qualcosa dietro al paywall e deciderà di inviare un link (tramite il proprio client di posta elettronica, non tramite WSJ) a un amico che non ha un account WSJ. Clicca, invia, fallisci. Chiaramente l'esperienza di mia sorella a quell'URL è diversa da quella della sua amica.

Relativo, ma non strettamente in tema: Sono nella fase iniziale di progettazione di un'applicazione progettata per supportare importanti sforzi di ricerca in rete (chiamata quest (pensa : segnalibri su steroidi e LSD)). Il proprietario della missione vuole condividere una visione particolare dei suoi dati con qualcun altro, ma questa visualizzazione richiede una combinazione di stato dell'interfaccia utente (ad esempio quali visualizzazioni di quali dati vengono visualizzati in quali riquadri) insieme alle autorizzazioni appropriate per accedere all'interfaccia utente e i dati visualizzati. C'è un sacco di stato memorizzato richiesto al destinatario per ottenere la vista desiderata.

La mia soluzione attuale è quella di memorizzare tutte le UI / ACL / le informazioni necessarie per la vista in un oggetto separato e restituire l'URL (probabilmente un UUID) per l'oggetto tale . Credo che l'accesso a visualizza oggetto possa essere considerato RESTful nel senso che tutti gli utenti in possesso ottengano le stesse informazioni / esperienze.

Do server-side sessions violate REST?

Lo fanno sicuramente! Quando si implementa REST, non ci deve essere alcuna sessione lato server, altrimenti si dispone di una soluzione ibrida RPC / REST.

Il cliente deve inviare a un servizio RESTful tutto il contesto necessario per soddisfare la richiesta, comprese le informazioni necessarie per autenticare il client, ogni volta che viene fatta una nuova richiesta. Il server è libero di memorizzare nella cache le informazioni per rendere più rapida la manutenzione delle richieste successive, ma le informazioni memorizzate nella cache non devono equivalere a una sessione lato server. In altre parole, la richiesta stessa deve contenere informazioni sufficienti per essere elaborata anche in assenza dello stato della cache.

Probabilmente dipende da cosa intendi per "dati di sessione". È un termine preciso?

La comunicazione sicura tra due parti implica spesso che il server generi (e memorizzi) un "token di accesso" a tempo limitato che il cliente deve fornire con ciascuna richiesta come modalità di autorizzazione. Questo token di accesso è già quello che chiamerei "dati di sessione": è archiviato lato server, limitato nel tempo e relativo a un client (di solito le sue autorizzazioni).

Sarei molto sorpreso se questo tipo di operazione fosse etichettato come non RESTful. OAuth è un esempio.

Non sono uno specialista e non sono molto fiducioso qui; Sto solo condividendo le mie conoscenze sperando che si dimostrino utili.

Il punto più importante di REST è che un URI di una risorsa punta sempre alla stessa risorsa. Quindi gli utenti possono passare un riferimento a questa risorsa e tutti vedono lo stesso. Questo è chiamato Representational State Transfer (REST). Se il server mantiene lo stato e fornisce una risorsa diversa per lo stesso URI, direi che questo non è più REST puro.

Le sessioni sono fondamentalmente utilizzate per aggiungere lo stato alle applicazioni RESTful stateless. Così formalmente, questo rende la tua applicazione RESTful di stato, tuttavia avere lo stato di mantenimento del server ti semplifica la vita, dal momento che non devi passare tutti i dati avanti e indietro su ogni richiesta / risposta.

Le sessioni e, più in generale, lo stato, ti permettono di evitare questo e questo ha alcuni vantaggi positivi in termini di prestazioni (meno trasferimento di dati) e sicurezza (meno dati disponibili per manomettere).

Quindi, mentre viola ufficialmente parte della definizione di REST, è così utile che è raro vedere le applicazioni RESTful che non usano lo stato tramite le sessioni.

Cosa Fielding intende per tale affermazione è che il server delle applicazioni che ospita l'API REST non associa lo stato dell'ambiente a una richiesta tramite una sorta di meccanismo dietro le quinte. Considera la differenza tra un server delle applicazioni e un server del database . Il vincolo REST è che il server delle applicazioni dovrebbe essere senza stato . Tuttavia, il server delle applicazioni può delegare le richieste per lo stato delle risorse al server del database in base alle informazioni che fanno parte della richiesta, come una combinazione utente / password nel Intestazione autorizzazione o Uri stessa. Dopotutto, REST si basa sul modello client / server.