2015-11-18 13 views
7

Kann ein Einkaufswagen mithilfe von REST-Architekturbeschränkungen implementiert werden?REST Einkaufswagen

Ich möchte meine Frage in Bezug auf Sitzungsstatus konzentrieren. In einer typischen MVC-Anwendung, die einen Einkaufswagen implementiert, wird das Sitzungsobjekt höchstwahrscheinlich in der Sitzung verwaltet, der Warenkorb als eine Liste von Produkten.

Wie würde derselbe Warenkorb verwaltet, wenn die Anwendung der REST-Architektur gefolgt wäre. Eine der REST-Einschränkungen ist die Verwaltung der Zuständigkeiten der Clients.

Sollte ein Einkaufswagen und sein Fortschritt vom Kunden verwaltet werden? Irgendwelche Beispiele? Irgendwelche Nachteile der Verwaltung des Status im Client in Bezug auf einen einfachen Einkaufswagen oder andere Unternehmensanwendungen?

+1

Sie sollten sich die defacto Hallo Welt von REST (RestBucks Coffee Shop) ansehen. – Aron

+0

Sie verbinden den Status der Sitzung im HTTP-Sinn des Begriffs und ein globales Objekt "Sitzung", das ein Artefakt ist, das von serverseitigen Frameworks bereitgestellt wird. – guillaume31

+0

Ich möchte klarstellen ... Warenkorb, natürlich wird in der Datenbank nach dem Einkauf gespeichert werden, ist die Frage nicht so grundlegend. Meine Frage bezieht sich auf die vierte REST-Einschränkung, die stateless kommuniziert, dh es sind keine Clientsitzungsdaten auf dem Server gespeichert. Und wo wird der Einkaufswagen ein Kunden sein? Diese Frage wird im Folgenden in Antworten geklärt. Vielen Dank. –

Antwort

3

In REST-Anwendungen wird der Sitzungsstatus vollständig vom Client verwaltet und die Anforderung muss alle erforderlichen Informationen enthalten, damit sie vom Server verstanden werden können. Wenn der Server beispielsweise eine Authentifizierung erfordert, muss jede Anfrage die Anmeldeinformationen enthalten.

Der REST stateless constraint wird wie folgt definiert:

5.1.3 Stateless

[...] jede Anforderung vom Client zum Server notwendig, alle Informationen enthalten muss, die verstehen Anfrage und kann keinen gespeicherten Kontext auf dem Server nutzen. Der Sitzungszustand wird daher vollständig auf dem Client gehalten. [...]

jedoch die staatenlos Constraint den Server nicht bedeuten sollte keine Daten speichern.

In Anwendungen, in denen der Sitzungsstatus vom Server verwaltet wird, ist es ein gängiger Ansatz, die Einkaufswagendaten in der HTTP-Sitzung zu speichern. Aber ein Einkaufswagen ist kein Sitzungsstatus. Und wahrscheinlich sollte es nicht vollständig vom Kunden verwaltet werden.

In REST, ein Einkaufswagen, kann eine Ressource durch eine URL wie /shopping-cart identifiziert und Operationen können darüber durchgeführt werden. Alle Einkaufswagendaten können in einer Datenbank auf dem Server gespeichert werden.

Any information that can be named can be a REST resource, auch ein Warenkorb:

5.2.1.1 Ressourcen und Resource Identifiers

Der Schlüssel Abstraktion von Informationen in REST ist eine Ressource. Jede Information, die benannt werden kann, kann eine Ressource sein: ein Dokument oder ein Bild, ein zeitlicher Dienst (z. B. "heutiges Wetter in Los Angeles"), eine Sammlung anderer Ressourcen, ein nicht virtuelles Objekt (z. B. eine Person) und so weiter . Mit anderen Worten, jedes Konzept, das das Ziel der Hypertext-Referenz eines Autors sein könnte, muss in die Definition einer Ressource passen. Eine Ressource ist eine konzeptionelle Zuordnung zu einer Menge von Entitäten, nicht zu der Entität, die der Zuordnung zu einem bestimmten Zeitpunkt entspricht. [...

  • GET /shopping-cart: Holen Sie sich das Warenkorb

    ]

Sie können Vorgänge wie diese auf Ihrem Warenkorb ausführen.

  • POST /shopping-cart: Fügen Sie einen Artikel zum Einkaufswagen hinzu (Senden einiger Daten mit dem Artikel, den Sie hinzufügen, und der Menge im Anfragetext).

  • DELETE /shopping-cart/1: Entfernen Sie einen Artikel mit der ID 1 aus dem Einkaufswagen.

  • PATCH /shopping-cart: Aktualisieren Sie den Einkaufswagen (Senden von Daten, die im Anfragetext aktualisiert werden sollen).

  • PUT /shopping-cart: Ersetzen Sie den gesamten Inhalt des Einkaufswagens (senden Sie einige Daten mit dem Inhalt Ihres Einkaufswagens im Anfragetext).

  • DELETE /shopping-cart: Entfernen Sie den Warenkorb

  • POST /shopping-cart/order:

  • So den Warenkorb Inhalt bestellen, beachten Sie den Client keine Informationen speichern über den Warenkorb jederzeit. Alle Informationen zum Einkaufswagen werden auf dem Server gespeichert.


    Weitere Informationen über REST, ich empfehle die chapter 5 von Roy T. Fieldings Lesen dissertation.

    +0

    Ein Nutzer kann 30 Minuten für den Einkauf einplanen, dann den Einkaufswagen senden, den Gesamtpreis sehen, einige Produkte aus dem Warenkorb entfernen und dann erneut übermitteln, wo der Einkaufswagen in einer solchen Client-Server-Interaktion verwaltet wird , im Kundencode? oder ist es basierend auf Ihrer obigen Erklärung in einer Datenbank gespeichert? –

    +0

    @SatBobbi Alle Einkaufswagendaten werden in einer Datenbank im Server gespeichert. –

    +0

    Danke für Ihre Antwort. Ich stimme nicht zu ... Wenn wir den Staat in der Datenbank speichern, schlägt er den Zweck der Beschränkung. Ich denke, wir würden keine REST-Anwendung für den Einkaufswagen benötigen, jede andere Webanwendung hätte das Design gelöst. Ich war auf der Suche nach einem Beispiel, wenn der Status vollständig im Client verwaltet wird oder Probleme bei der vollständigen Verwaltung des Zustands im Client auftreten können. –

    2

    Eine Menge Verwirrung über REST existiert, weil viele Leute von REST-Einschränkungen hören und denken, dass sie Regeln sind, die aus keinem anderen Grund angewendet werden, als der Architektur als Selbstzweck zu folgen.

    Die eigentliche Frage, die Sie sich stellen sollten, ist, warum die statusfreie Einschränkung in REST existiert und welche Vorteile Sie daraus ziehen. Denken Sie daran, dass REST ein Architekturstil ist, der für die langfristige Entwicklung großräumiger verteilter Systeme gedacht ist. Sie werden einfach nicht die Probleme haben, die REST in einer kleinen Anwendung lösen soll, wo eine einzige Datenbank alle Ihre Informationen enthält.

    Die statusfreie Einschränkung induziert die Eigenschaft der Sichtbarkeit, Zuverlässigkeit und Skalierbarkeit. Die Sichtbarkeit wurde verbessert , da ein Überwachungssystem nicht über ein einziges Anfragedatum hinausschauen muss, um die vollständige Natur der Anfrage zu ermitteln. Die Zuverlässigkeit wird verbessert, da sie die Wiederherstellung von Teilausfällen erleichtert, die von stammen. Die Skalierbarkeit wird verbessert, da der Status zwischen den Anforderungen nicht gespeichert werden muss, um die Serverkomponente schnell auf freie Ressourcen zu verteilen und die Implementierung weiter zu vereinfachen, da der Server die Ressourcennutzung nicht über Anforderungen hinweg verwalten muss.

    Wenn also zustandslos ist, bedeutet dies, dass die Clientanforderung alle erforderlichen Informationen zur Verarbeitung haben sollte.

    Wie wichtig ist die Sichtbarkeit für Sie? Möchten Sie den gesamten Inhalt des Einkaufswagens aus der Client-Anfrage sehen können, wenn Sie etwas debuggen, oder sind Sie damit einverstanden, diese Informationen aus den Datenbanken zu bekommen?

    Wie wichtig ist Zuverlässigkeit? Verfügen Sie über ein großes verteiltes System mit mehreren Servern und Datenbanken? Wenn Sie ein großes verteiltes System haben, in dem die Einkaufswageninformationen abhängig vom genauen HTTP-Server, der die Anfrage beantwortet hat, in verschiedenen Datenbanken gespeichert werden, kann bei einem Serverausfall nur ein anderer Server aus dieser Gruppe die Anfrage erfüllen und die Sitzung beenden oder ein Server aus einer anderen Gruppe wird den Client zwingen, die Sitzung neu zu starten. Wenn alle Informationen in der Anfrage enthalten sind, kann jeder Server dies tun.

    Wie wichtig ist Skalierbarkeit? Wenn Sie ein verteiltes System haben und Einkaufswageninformationen in einer einzigen Datenbank speichern, wird es zu einem Trichter für alle Ihre Anfragen und Sie verlieren die Skalierbarkeit. Wenn Sie es in mehreren Datenbanken speichern, verlieren Sie die Zuverlässigkeit wie oben beschrieben.

    Also, haben Sie ehrgeizige langfristige Ziele oder wird Ihre Anwendung groß genug sein, dass Sie die Probleme REST-Versuche zu lösen haben? Wenn Sie immer ein paar Server und eine einzige Datenbank haben und diese für jede einzelne Anfrage verwenden, spielt es keine Rolle, ob Sie staatenlos sind oder nicht. Sie können einfach eine /shopping_cart Ressource oder etwas ähnliches haben, fügen Sie dazu Zeug mit POST Anfragen hinzu, und schließen oder löschen Sie es, wenn Sie fertig sind.

    Wenn Ihre Daten über mehrere Datenbanken verteilt werden, reagieren viele HTTP-Server auf Anforderungen, Cache-Server usw. und Sie möchten Kapazität dynamisch bereitstellen, indem Sie neue Server nach Bedarf einrichten und konfigurieren Entfernen Sie sie, wenn die Last reduziert ist, dann gehen Sie völlig statuslos und verlassen Sie den Warenkorb mit dem Client.

    +0

    Vielen Dank! Bevor ich mich erkundigte, dass diese Einschränkung die Skalierbarkeit adressiert, spricht die gleiche Einschränkung Zuverlässigkeit und Sichtbarkeit an! So verlasse ich gerne den Zustand mit dem Client, da die vorgesehene Anwendung eine groß angelegte verteilte Anwendung ist. Ich möchte diese Nachfolgefrage stellen, indem ich das durchführe, was ich gerade lese. Die HTTP-Implementierung von REST führt zu Problemen mit "Sicherheit auf Nachrichtenebene und verteilten Transaktionen". Gegeben, wie rechtfertigen Sie Ihren obigen Kommentar "Denken Sie daran, dass REST ein Architekturstil ist, der für die langfristige Entwicklung großräumiger verteilter Systeme gedacht ist". –

    6

    Es ist nichts falsch daran, den Einkaufswagen als Ressource auf dem Server zu speichern. Es ist Sitzungsstatus, die auf dem Client gespeichert werden sollte. https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_3

    Um zustandslos zu sein, sollte Ihre Warenkorb-URI in der Lage sein, einen eindeutigen Einkaufswagen zu identifizieren, ohne sich auf Sitzungsinformationen verlassen zu müssen.

    Zum Beispiel ist /shopping-cart wahrscheinlich nicht ausreichend, es sei denn, es wird immer nur einen Einkaufswagen in Ihrer Anwendung geben.

    Wahrscheinlich wird es mindestens einen Warenkorb pro Benutzer geben. Also könnten Sie etwas wie /user/1234/shopping-cart oder /shopping-cart?userID=1234 verwenden.

    Noch wahrscheinlicher, Sie müssen wahrscheinlich mehrere Einkaufswagen für jeden Benutzer haben. Sie sollten also Ihren Einkaufswagen eine eindeutige ID wie /user/1234/shopping-cart/5678 oder nur /shopping-cart/5678 geben.

    Der Punkt ist, alles, was zur Bearbeitung der Anfrage benötigt wird, sollte in der Anfrage sein.

    +0

    Danke, ja, es macht Sinn, Einkaufswagen eine adressierbare Ressource auf dem Server zu machen, am ehesten in der Richtung von/purchase-order/shopping-cart –

    +1

    Ich habe keine Ahnung, warum jemand dies abgelehnt hat. Es ist die bisher genaueste Antwort IMO. Vergessen Sie niemals, dass REST beschreibt, was im Webspace passiert, nicht im Bereich der Anwendung. – guillaume31

    +0

    Ich stimme mit Ihrer Antwort in Bezug auf Adress-Fähigkeit des Einkaufswagens auf dem Server überein, Status auf dem Client verlassend. nicht genug Ruf, um deine Antwort zu finden. danke für die Antwort. nicht sicher, was Sie mit "REST beschreibt, was im Webspace passiert, nicht im Bereich der Anwendung". Vielen Dank. –

    0

    Ja, Sie können,

    Warenkorb Daten (schöpfender Produkte) auf der Kunden-Sitzung gespeichert werden, das ist kein Problem.

    Dann, sobald der Benutzer/checkout, der Warenkorb sollte in der DB auf dem Server persistent sein. Der Schlüssel zur Ruhe ist, dass jede Petition, die der Klient vorlegt, alle Daten enthalten muss, um sich zu identifizieren. Ich schlage vor, etwas über JWT oder OAuth zu lesen.

    Die App selbst würde wie jede andere Warenkorb-App funktionieren, die Sie gesehen haben, die meisten von ihnen nicht den Warenkorb in DB beharren, nur speichern Sie die Clients-Sitzung.

    Verwandte Themen