Verstoßen serverseitige Sitzungen gegen REST?

14

Laut Roy Fielding (einem der Hauptautoren der HTTP-Spezifikation) erwähnt er in seiner wegweisenden These Architectural Styles bei der Diskussion von REST :

[E] Jede Anfrage vom Client an den Server muss alle Informationen enthalten, die zum Verständnis der Anfrage erforderlich sind, und kann keinen auf dem Server gespeicherten Kontext nutzen.

Unter "gespeichertem Kontext" versteht er den Anwendungsstatus, z. B. die Seitenzahl für die nächste Seite, im Vergleich zum Ressourcenstatus, z. B. ein beliebiger Datenspeicher, ein Bild usw. - was wohl der ganze Punkt von REST ist.

Ist es gerechtfertigt zu sagen, dass die meisten Versuche einer reinen Pause (hier definiert als eine Implementierung, die der obigen These entspricht) fehlschlagen müssen, weil sie darauf angewiesen sind, Sitzungsdaten auf dem Server zu speichern (dauerhaft oder anderweitig)?

Das Konzept einer Sitzung ist - insbesondere für Webentwickler - üblich, aber ist es gemäß der obigen Definition REST-konform?

rest

— Matt
quelle

2

Ich würde sagen, nach dieser Definition ist praktisch nichts ruhiger, aber wie ist diese Definition überhaupt einigermaßen logisch? Stellen Sie sich eine "erholsame" Google-Suche vor, bei der Sie einen Index des Internets angeben müssen, damit Google nach Ihnen sucht. Was? Nein, wenn Sie sagen, dass Sie keinen Persistenzspeicher haben können und erholsam sind, bedeutet dies, dass erholsame Schnittstellen in der Tat sinnlos sind. Das bedeutet nicht, dass wir alle anfangen sollten, In-Memory-Sitzungen zu pflegen und zu sagen, dass es immer noch ein gutes Design für die Erholung ist ...

— Jimmy Hoffa

3

Ich denke, es sollte beachtet werden, dass es einen Unterschied zwischen dem Anwendungsstatus und dem Ressourcenstatus gibt (der Google-Index wäre der Ressourcenstatus und ist absolut legitim). Ich sollte das in der Frage klarer machen.

— Matt

gibt es so einen unterschied? Bitte definieren Sie es. :) Ich habe gesehen, wie Leute versucht haben, diese zu definieren, aber es wird wirklich unscharf, weil sie eigentlich nicht anders sind. Sie sind beide veränderbare Daten. Die einzige relevante Unterscheidung zwischen einer Staatsform und einer anderen ist, ob sie dauerhaft ist oder nicht, wobei die Nicht-Form bedeutet, dass sie normalerweise regenerierbar ist, was sie unterscheidet.

— Jimmy Hoffa

1

Ich habe mich das selbst gefragt. Da noch niemand erklärt hat, warum meine Bewerbung einen goldenen "erholsamen" Stern haben soll, kümmere ich mich auch nicht wirklich darum.

— bA

10

Ich würde ja sagen, der Sitzungsstatus macht eine RESTful-App nicht-RESTful. Triviales Beispiel, meine Schwester abonniert das Wall Street Journal. Regelmäßig liest sie etwas hinter der Paywall und beschließt, einen Link (über ihren eigenen E-Mail-Client, nicht über WSJ) an einen Freund zu senden, der kein WSJ-Konto hat. Klicken, senden, fehlschlagen. Offensichtlich unterscheidet sich die Erfahrung meiner Schwester unter dieser URL von der ihrer Freundin.

Verwandt, aber nicht themenbezogen: Ich befinde mich in der frühen Entwurfsphase einer Anwendung, die erhebliche Forschungsbemühungen im Internet unterstützen soll (so genannte Quests (think: Lesezeichen für Steroide und LSD)). Der Besitzer der Quest möchte eine bestimmte Ansicht seiner Daten mit einer anderen Person teilen. Für diese Ansicht ist jedoch eine Kombination aus dem Status der Benutzeroberfläche (z. B. welche Visualisierungen welcher Daten in welchen Bereichen angezeigt werden) und den entsprechenden Berechtigungen für den Zugriff auf die Benutzeroberfläche erforderlich und die angezeigten Daten. Es ist eine Menge Speicherstatus erforderlich, damit der Empfänger die beabsichtigte Ansicht erhält.

Meine aktuelle Lösung besteht darin, alle für die Ansicht erforderlichen UI / ACL / Informationen in einem separaten Objekt zu speichern und die URL (wahrscheinlich eine UUID) für dieses Objekt zurückzugeben. Ich glaube, dass der Zugriff auf das Ansichtsobjekt in dem Sinne als RESTful angesehen werden kann, dass jeder, der im Besitz davon ist, die gleichen Informationen / Erfahrungen erhält.

— Peter Rowell
quelle

1

Ihr Ansichtsobjektbeispiel ist ein anderer Winkel dazu. Ordentlich.

— Matt

Akzeptiere dies als die Antwort, trotz der anderen tollen Antworten, hauptsächlich, weil es die Frage direkt beantwortet und ein sehr klares Beispiel gibt. Auch der zweite Teil der Ansichtsobjekte zeigte die Waage.

— Matt

1

Wenn Sie sagen, dass wsj site ein Beispiel für eine nicht erholsame App ist, würde ich nicht zustimmen, dass Ihr Beispiel dies zeigt. Wenn sich die WSJ-Site zum Beispiel auf Daten stützt, die vollständig vom Kunden Ihrer Schwester angegeben wurden, um ihr die Daten zu präsentieren, handelt es sich nach der Definition von @Matt um RESTful. Wenn es sich jedoch auf den temporären Sitzungsstatus im Speicher stützt, ist es laut Definition von Matt nicht RESTful. Ich weise nur darauf hin, weil die Definition, die Matt gegeben hat, auf Implementierungsspezifikationen basiert, während REST durch die Verbrauchstechnik besser definiert ist.

— Jimmy Hoffa

@ JimmyHoffa - Mein Verständnis der REST-Einschränkungen ist, dass es zustandslos ist . Das scheint mir ziemlich eindeutig zu sein.

— Peter Rowell

Wenn die WSJ-Anwendung keinen Status hätte, müsste der sichtbare Artikel vom Client gesendet werden. Dieser Artikel kann jederzeit von den Site-Administratoren bearbeitet werden. Machen Sie keinen Fehler, es ist ein Teil des Status der WSJ-App. Ich denke, die angestrebte Unterscheidung besteht darin, dass es sich um einen dauerhaften Zustand handelt, der mehr Garantien und weniger Verwaltungsaufwand als ein unbeständiger Zustand wie z. B. Sitzungen bietet, zusammen mit einer einfacheren Kontrolle der Atomizität der Transaktionen. Dies zusammen mit dem einfachen Konsummodell sind das, wofür sich die Menschen ausruhen wollen. (Ich denke)

— Jimmy Hoffa

2

Verstoßen serverseitige Sitzungen gegen REST?

Das tun sie definitiv! Wenn Sie REST implementieren, darf keine serverseitige Sitzung vorhanden sein, andernfalls verfügen Sie über eine hybride RPC / REST-Lösung.

Der Client muss bei jeder neuen Anforderung den gesamten für die Bearbeitung der Anforderung erforderlichen Kontext, einschließlich der zur Authentifizierung des Clients erforderlichen Informationen, an einen RESTful-Service senden. Es steht dem Server frei, Informationen zwischenzuspeichern, um die Bearbeitung nachfolgender Anforderungen zu beschleunigen. Die zwischengespeicherten Informationen dürfen jedoch keine serverseitige Sitzung sein. Mit anderen Worten, die Anforderung selbst muss genügend Informationen enthalten, um auch ohne den zwischengespeicherten Status verarbeitet zu werden.

— dasblinkenlight
quelle

1

Kommt wahrscheinlich darauf an, was du mit "Sitzungsdaten" meinst. Ist das ein genauer Begriff?

Bei der sicheren Kommunikation zwischen zwei Parteien muss der Server häufig ein zeitlich begrenztes "Zugriffstoken" generieren (und speichern), das der Client mit jeder Anforderung als Art der Autorisierung bereitstellen muss. Dieses Zugriffstoken ist bereits das, was ich "Sitzungsdaten" nennen würde - es wird serverseitig, zeitlich begrenzt und auf einen Client bezogen (normalerweise seine Berechtigungen) gespeichert.

Es würde mich sehr wundern, wenn diese Art von Operation als nicht-REST-konform eingestuft würde. OAuth ist ein Beispiel.

Ich bin kein Spezialist und ich bin hier nicht sehr zuversichtlich. Ich teile nur meine Erkenntnisse in der Hoffnung, dass sie sich als hilfreich erweisen.

— Kos
quelle

1

Der wichtigste Punkt von REST ist, dass ein URI zu einer Ressource immer auf dieselbe Ressource verweist. So können Benutzer einen Verweis auf diese Ressource weitergeben, und jeder sieht das Gleiche. Dies wird als Representational State Transfer (REST) bezeichnet. Wenn der Server den Status beibehält und eine andere Ressource für denselben URI liefert, würde ich sagen, dass dies kein reiner REST mehr ist.

— Puckl
quelle

Das ist nicht unbedingt so, dass Benutzer dasselbe sehen. Access kann vorgeben, wie viel ein Benutzer sehen darf.

— Erik

@Erik Der Benutzer würde jedoch angeben, wie viel er in der Anfrage sehen möchte (einschließlich der Verwendung des Accept-Headers), sodass Puckls Antworten zutreffen.

— Johan

1

@Johan Ich würde verschiedene Daten für verschiedene Benutzer vom selben Endpunkt zurückgeben. Ansonsten, was ist der Sinn der Authentifizierung des Benutzers.

— Erik

@Erik Das würde ich auch machen. Trotzdem glaube ich, dass die Authentifizierung außerhalb des Status der Ressource liegt. Wenn die Ansicht also vom authentifizierten Benutzer beeinflusst wird, ist sie nicht mehr REST-fähig. Wenn Sie Ihr RESTful-Badge haben möchten, sollten Sie möglicherweise mehrere "Ansichten" der Ressource erstellen, je nachdem, wer Zugriff anfordert, und nur für einige der Ansichten Zugriffsberechtigungen erteilen. So kann die Öffentlichkeit Zugriff auf / userprofiles / {userID} / publicview erhalten und der Benutzer erhält Zugriff auf / userprofiles / {userID} / fullprofile und berechtigte Freunde erhalten Zugriff auf / userprofiles / {userID} / friendsview

— Johan

0

Sitzungen werden im Wesentlichen verwendet, um zustandslosen, REST-konformen Anwendungen einen Status hinzuzufügen. Dies macht Ihre RESTful-Anwendung formal zwar statusbehaftet, der Server-Keep-Status vereinfacht jedoch Ihr Leben, da Sie nicht bei jeder Anforderung / Antwort alle Daten hin und her geben müssen.

In Sitzungen und allgemeiner gesagt, können Sie dies vermeiden. Dies hat einige positive Vorteile für die Leistung (weniger übertragene Daten) und die Sicherheit (weniger Daten, die manipuliert werden können).

Obwohl es offiziell einen Teil der Definition von REST verletzt, ist es so nützlich, dass es selten REST-fähige Anwendungen gibt, die den Status nicht über Sitzungen verwenden.

— Oleksi
quelle

Ich stimme dir nicht zu. Sie haben eine Shopping-Site, auf der Sie nach Marke, Farbe und Größe filtern können. Herkömmliche Web 1.0-Websites würden dies mit einigen Kontrollkästchen, einer serverseitigen Sitzung und POST handhaben. Wenn ich den Link zu example.org/shirts freigeben möchte, wird nicht angezeigt, dass ich "Mittel", "Schwarz" und "Roots" ausgewählt habe. (Dies führt auch zu der hässlichen Meldung "Sie senden Daten erneut", wenn Sie auf "Zurück" klicken.) Wenn ich jedoch den Link zu (z. B.) example.org/shirts/medium-black-roots teile, hat jeder die gleiche Darstellung. Alle erforderlichen Statusinformationen befinden sich in der URL (oder im POST-Text, falls erforderlich, aber Sie können dies nicht freigeben).

— Jesse Buchanan

... RESTful ist vielleicht nicht für alles geeignet. Ist Ihre hypothetische Anwendung ressourcenorientiert (eine Shopping-Site ist es sicherlich!)? Vielleicht passt es nicht zu einer RIA mit viel Staat, die nicht ressourcenorientiert ist. Ich kann mir ehrlich gesagt keine guten Beispiele vorstellen.

— Jesse Buchanan

0

Fielding meinte mit dieser Anweisung, dass der Anwendungsserver, auf dem sich die REST-API befindet, den Umgebungszustand nicht mit einer Anforderung durch einen Mechanismus im Hintergrund verknüpft. Betrachten Sie den Unterschied zwischen einem Anwendungsserver und einem Datenbankserver . Die REST-Einschränkung besteht darin, dass der Anwendungsserver statusfrei sein sollte . Der Anwendungsserver kann jedoch Anforderungen für den Ressourcenzustand an den Datenbankserver delegieren, basierend auf Informationen, die Teil der Anforderung sind, z. B. eine Benutzer- / Kennwortkombination im Authorization-Header oder im Uri selbst. Schließlich basiert REST auf dem Client / Server-Modell.

— eulerfx
quelle