Verfolgung nach dem Zurück-Button

Question

Ich möchte ein Web-App-Bestellsystem mit der REST-Methode zum ersten Mal schreiben. Ich verstehe das Konzept der "Nachrichten-ID", wenn Dinge auf einer Seite gepostet werden, aber dieses Szenario kommt auf. Sobald ein Nutzer in die Web-App schreibt, können Sie seinen Status mit einer an den URI angehängten ID verfolgen, aber was passiert, wenn er den Zurück-Button des Browsers auf den Einstiegspunkt der App drückt, wenn er keine ID hat ? Sie verlieren dann ihren Status in der Transaktion.

Ich weiß, dass Sie ihnen immer einen Keks geben können, aber Sie können das nicht tun, wenn sie Cookies ausgeschaltet haben und, schlimmsten Fall denken hier, sie haben auch Javascript deaktiviert.

Jetzt verstehe ich die Antwort vielleicht "Ja, das ist, was passieren wird", das ist das Ende der Geschichte, und ich kann damit leben, aber da ich neu bin, gibt es etwas, das mir fehlt?

Answer 1

Die Antwort ist, dass Ihre Anwendung (in einem REST-Szenario) einfach nicht verfolgen, was passiert. Der gesamte Status wird vom Client verwaltet, und Statusübergänge werden über die URI-Navigation ausgeführt. Der Teil "Statusübertragung" von REST bezieht sich auf die Clientnavigation zu neuen URIs, bei denen es sich um neue Status handelt.

Ein URI, auf den mit GET zugegriffen wird, ist effektiv eine schreibgeschützte Operation, sowohl gemäß der HTTP-Spezifikation als auch der REST-Methode. Das bedeutet, wenn der Client einen vorherigen URI "sichert", "das Schlimmste", das passiert, ist, dass ein anderer GET gemacht wird und mehr Daten geladen werden.

Lassen Sie uns sagen, dass der Kunde dies tut (stark vereinfachte pseudo-HTTP) ...

GET //site.com/product/123

Dies ruft Informationen (oder vielleicht eine Seite) zum Produkt ID 123, die vermutlich einen Verweis auf einen URI enthält, der verwendet werden kann, um diesen Artikel in den Warenkorb des Benutzers zu senden. So entscheidet der Benutzer, den Artikel zu kaufen. Wieder ist es stark vereinfacht aber:

POST //site.com/shoppingcart/ {productid = 123}

Die Rückkehr aus könnte dies eine Darstellung des Einkaufswagens oder ein Verweis auf das hinzugefügte Element sein (die mit dem Befehl DELETE (um den Artikel wieder zu entfernen) verwendet werden kann, oder eine Vielzahl anderer Dinge (wie tieferes XML, das den Inhalt des Einkaufswagens mit anderen URIs beschreibt, die auf die Einkaufswagenartikel und zurück zu den ursprünglichen Produkten verweisen). Es hängt alles von dir ab.

Aber der "Zustand" ist definiert durch was auch immer der Client tut. Es wird auf dem Server überhaupt nicht verfolgt, obwohl Sie sicher eine Kopie seines Einkaufswageninhalts in Ihrer Datenbank für einige Zeit behalten werden. (Ich kam zwei Jahre später einmal auf eine Website zurück und meine Einkaufswagen waren immer noch da ...) Aber es liegt an ihm, den Ausweis im Auge zu behalten. Für Ihre Server-App ist es nur ein weiterer Datensatz, vermutlich mit einer Art Ablaufdatum.

Auf diese Weise benötigen Sie keine Cookies und Javascript ist völlig abhängig von der Client-Implementierung. Es ist schwierig, einen anständigen REST-Client ohne Skript zu erstellen - Sie könnten wahrscheinlich etwas mit XSLT erstellen und nur XML vom Server zurückgeben, aber das ist wahrscheinlich mehr Schmerz, als irgendjemand benötigt.

Der Ausgangspunkt ist REST wirklich zu verstehen, dann das System zu entwerfen und dann zu bauen. Es eignet sich definitiv nicht dazu, es wie bei den meisten anderen Systemen on-the-fly zu bauen (richtig oder falsch).

Dies ist ein ausgezeichneter Artikel, dass Ihnen einen ziemlich „reinen“ Blick auf REST mit Code, ohne sie zu abstrakt und ohne bogging Sie nach unten gibt:

http://www.infoq.com/articles/subbu-allamaraju-rest

Answer 2

REST hat keine Zustände serverseitig; Sie zeigen einfach auf Ressourcen. Benutzersitzungen werden nicht verfolgt; Stattdessen werden Cookies verwendet, um den Anwendungsstatus zu verfolgen. Wenn Sie jedoch feststellen, dass Sie wirklich einen Sitzungsstatus benötigen, müssen Sie REST unterbrechen und auf dem Server nachverfolgen.

Ein paar Dinge zu beachten:

• Wie viele Ihrer Benutzer haben Cookies sowieso deaktiviert? Wie viele wissen das überhaupt?
• Ist es wirklich wahrscheinlich, dass Ihre Benutzer JS ausgeschaltet haben? Wenn ja, wie werden Sie PUT (Bearbeiten) und DELETE (Löschen) ohne AJAX erreichen?

EDIT: Da Sie wollen keine Cookies und JavaScript erzwingen, dann können Sie nicht wirklich RESTful-System haben. Aber Sie können es etwas vortäuschen. Sie müssen eine Benutzer-Server-Seite verfolgen. Sie können dies mit einem Sitzungsobjekt tun, wie es in Ihrer Sprache/Ihrem bevorzugten Framework zu finden ist, oder indem Sie der Datenbank ein Feld hinzufügen, was immer Sie wissen wollen. Natürlich, wenn der Benutzer den Zurück-Knopf drückt, werden sie wahrscheinlich zu einer zwischengespeicherten Seite gehen. Wenn das nicht OK ist, müssen Sie die Header ändern, um das Zwischenspeichern zu verbieten. Grundsätzlich wird es komplizierter, wenn Sie keine Cookies verwenden, aber nicht unübersichtlich.

Was ist mit den fehlenden HTTP-Methoden PUT und DELETE? Sie können diese mit POSTs und einem versteckten Parameter fälschen, die angeben, ob Sie etwas neu machen, etwas bearbeiten oder einen Datensatz löschen. Das GET sollte sich nicht wirklich ändern.

Answer 3

Es stimmt, dass das "S" in REST für "state" und das "T" für "transfer" steht. Aber der Status wird auf dem Client gespeichert, nicht auf dem Server. Der Auftraggeber hat immer alle notwendigen Informationen, um selbst zu entscheiden, in welche Richtung er den Staat wechseln will.

So wie Sie es beschreiben, ist Ihr System nicht erholsam.