Le sessioni sul lato server violano il REST?

14

Secondo Roy Fielding (uno dei principali autori della specifica HTTP) nella sua tesi fondamentale sugli stili architettonici quando parla di REST , menziona:

Ogni richiesta dal client al server deve contenere tutte le informazioni necessarie per comprendere la richiesta e non può trarre vantaggio da alcun contesto memorizzato sul server.

Per "contesto memorizzato" si riferisce allo stato dell'applicazione, ad es. Quale sia il numero di pagina per la pagina successiva rispetto allo stato della risorsa, ad esempio qualsiasi archivio di dati, immagine, ecc., Che è probabilmente l' intero punto di REST.

È corretto affermare che la maggior parte dei tentativi di puro riposo (qui definiti come un'implementazione conforme alla tesi di cui sopra) deve fallire a causa della loro dipendenza dall'archiviazione dei dati di sessione sul server (persistente o meno)?

Il concetto di sessione è comune, in particolare per gli sviluppatori Web, ma è RESTful secondo la definizione di cui sopra?

rest

— opaco
fonte

2

Direi che in base a tale definizione praticamente nulla è riposante, ma in che modo tale definizione è ragionevolmente logica? Immagina una ricerca "riposante" su Google, in cui devi fornire un indice di Internet nella richiesta a google affinché possa cercarti. Che cosa? No, dire che non si può avere un negozio di persistenza ed essere riposanti equivarrebbe a dire che le interfacce riposanti sono in realtà inutili. Ciò non significa che dovremmo tutti iniziare a mantenere sessioni in memoria e dire che è ancora un buon progetto di riposo ...

— Jimmy Hoffa,

3

Penso che si dovrebbe notare che esiste una distinzione tra stato dell'applicazione e stato delle risorse (l'indice di Google sarebbe stato delle risorse ed è perfettamente legittimo). Dovrei renderlo più chiaro nella domanda.

— Matt,

c'è una tale distinzione? Per favore, definiscilo. :) Ho visto persone provare a definirle prima, ma diventa davvero confuso perché in realtà non sono diverse. Sono entrambi dati mutabili, l'unica distinzione rilevante tra una forma di stato e un'altra è se sia persistente o no, dove la non forma significa che è di solito rigenerabile, che è ciò che lo rende diverso.

— Jimmy Hoffa,

1

Me lo sono chiesto da solo. Dato che nessuno ha mai spiegato perché la mia candidatura dovrebbe desiderare una stella d'oro "riposante" o non me ne preoccupo.

— psr

10

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

Correlati, ma non strettamente in tema: sono nella prima fase di progettazione di un'applicazione progettata per supportare significativi sforzi di ricerca in rete (chiamati ricerche (pensate: segnalibri su steroidi e LSD)). Il proprietario della ricerca desidera condividere una vista particolare dei suoi dati con qualcun altro, ma questa vista richiede una combinazione di stato dell'interfaccia utente (ad es. Quali visualizzazioni di quali dati vengono visualizzati in quali riquadri) insieme alle autorizzazioni appropriate per accedere all'interfaccia utente e i dati visualizzati. È necessario molto stato memorizzato per consentire al destinatario di ottenere la vista desiderata.

La mia soluzione attuale è quella di memorizzare tutte le / qualsiasi informazioni UI / ACL necessari per la vista in un oggetto separato e restituire l'URL (probabilmente un UUID) per quel oggetto. Credo che l'accesso all'oggetto vista possa essere considerato RESTOSO, nel senso che chiunque ne sia in possesso ottiene la stessa informazione / esperienza.

— Peter Rowell
fonte

1

Sei vista degli oggetti esempio è un altro angolo su questo. Neat.

— Matt,

Accettarlo come risposta, nonostante le altre grandi risposte, soprattutto perché risponde direttamente alla domanda e fornisce un esempio molto chiaro. Inoltre, la seconda porzione sugli oggetti di visualizzazione inclinava le scale.

— Matt,

1

Se stai dicendo che il sito wsj è un esempio di app non riposante, non sarei d'accordo sul fatto che il tuo esempio lo mostri. Se ad esempio il sito WSJ si basa sui dati forniti completamente dal cliente di tua sorella per presentarle i dati, allora è per definizione @Matt dato, RESTful. Se tuttavia si basa sullo stato della sessione temporanea in memoria, è per definizione che Matt ha dato non RESTful. Lo sottolineo semplicemente perché la definizione fornita da Matt si basa su specifiche di implementazione mentre REST è meglio definito dalla tecnica di consumo.

— Jimmy Hoffa,

@JimmyHoffa - La mia comprensione dei vincoli di REST è che è apolide . Mi sembra abbastanza inequivocabile.

— Peter Rowell,

Se l'applicazione WSJ non avesse uno stato, l'articolo visualizzabile dovrebbe essere inviato dal client. Quell'articolo può essere modificato in qualsiasi momento dagli amministratori del sito, non commettere errori è un pezzo dello stato dell'app WSJ. Penso che la distinzione perseguita sia che si tratta di uno stato persistente , quindi avrà più garanzie e meno spese generali di gestione rispetto allo stato impersistente come le sessioni, insieme a un controllo dell'atomicità più semplice nelle transazioni su di esso. Questo, insieme al semplice modello di consumo, è ciò per cui le persone vogliono riposare. (Penso)

— Jimmy Hoffa,

2

Le sessioni sul lato server violano il REST?

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

Il client 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 effettuata una nuova richiesta. Il server è libero di memorizzare nella cache le informazioni per velocizzare la gestione delle richieste successive, ma le informazioni memorizzate nella cache non devono equivalere a una sessione sul lato server. In altre parole, la richiesta stessa deve contenere informazioni sufficienti per essere elaborata anche in assenza dello stato memorizzato nella cache.

— dasblinkenlight
fonte

1

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

La comunicazione sicura tra due parti spesso implica che il server generi (e memorizzi) un "token di accesso" limitato nel tempo che il client deve fornire a ciascuna richiesta come modo di autorizzazione. Questo token di accesso è già ciò che definirei "dati di sessione": è archiviato sul lato server, limitato nel tempo e correlato a un client (di solito le sue autorizzazioni).

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

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

— Kos
fonte

1

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

— Puckl
fonte

questo non è necessariamente vero che gli utenti vedranno la stessa cosa. L'accesso può determinare quanto un utente può vedere.

— Erik

@Erik Ma l'utente dovrebbe dichiarare quanto desidera vedere nella richiesta (incluso l'utilizzo dell'intestazione Accept), quindi le risposte di Puckl sono vere.

— Johan,

1

@Johan Vorrei restituire dati diversi per utenti diversi, dallo stesso endpoint. Altrimenti qual è il punto di autenticare l'utente.

— Erik,

@Erik Lo farei anche io. Tuttavia, credo che l'autenticazione sia al di fuori dello stato della risorsa, quindi in senso stretto se la vista è influenzata dall'utente autenticato, non è più RESTful. Forse se volevi il tuo badge RESTful dovresti creare più "viste" della risorsa, a seconda di chi richiede l'accesso autorizza l'accesso solo ad alcune delle viste. Quindi pubblico può accedere a / userprofiles / {userID} / publicview e l'utente ottiene l'accesso a / userprofiles / {userID} / fullprofile e gli amici autorizzati possono accedere a / userprofiles / {userID} / friendsview

— Johan

0

Le sessioni vengono sostanzialmente utilizzate per aggiungere lo stato alle applicazioni senza stato e RESTful. Quindi, formalmente, questo rende la tua applicazione RESTful con stato, tuttavia avere il server mantieni lo stato rende la tua vita un po 'più semplice, dal momento che non devi passare tutti i dati avanti e indietro su ogni richiesta / risposta.

Le sessioni, e più in generale lo affermano, consentono di evitarlo, e questo ha alcuni benefici positivi in termini di prestazioni (meno dati trasferiti) e sicurezza (meno dati disponibili da manomettere).

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

— Oleksi
fonte

Non sono d'accordo. Hai un sito di shopping che ti consente di filtrare per marca, colore e dimensioni. I siti Web Web 1.0 tradizionali lo gestiranno con alcune caselle di controllo, una sessione sul lato server e POST. Se voglio condividere il link su example.org/shirts, le persone non vedranno che ho selezionato Medio, Nero e Radici. (Questo provoca anche il brutto messaggio "stai ripubblicando i dati" quando fai clic indietro.) Ma se condivido il link a (ad esempio) example.org/shirts/medium-black-roots, ognuno ha la stessa rappresentazione. Tutte le informazioni sullo stato necessarie si trovano nell'URL (o nel corpo POST se necessario, ma non è possibile condividerle).

— Jesse Buchanan,

... RESTful potrebbe non essere adatto a tutto. La tua ipotetica applicazione è orientata alle risorse (un sito di shopping lo è sicuramente!)? Forse potrebbe non essere adatto per una RIA, con molto stato, che non è orientato alle risorse. Non riesco a pensare a nessun buon esempio per essere onesto.

— Jesse Buchanan,

0

Ciò che Fielding intendeva con questa affermazione è che il server delle applicazioni che ospita l'API REST non associa lo stato ambientale a una richiesta tramite una sorta di meccanismo dietro le quinte. Considera la differenza tra un server delle applicazioni e un server di database . Il vincolo REST è che il server delle applicazioni deve essere senza stato . Tuttavia, il server delle applicazioni può delegare le richieste per lo stato delle risorse al server di database in base alle informazioni che fanno parte della richiesta, ad esempio una combinazione utente / password nell'intestazione Autorizzazione o Uri stesso. Dopotutto, REST si basa sul modello client / server.

— eulerfx
fonte