Ich versuche, beim Erstellen von Anwendungen so REST-konform wie möglich zu sein, aber eine Sache, über die ich nie sicher bin, ist, wie man einen Workflow vom Wizard-Typ erstellt, der REST-konform und prägnant ist.
Nehmen Sie beispielsweise einen mehrseitigen Anmeldeprozess vor.
Option 1: Ich kann für jeden Schritt einen Controller erstellen und neu oder bearbeiten aufrufen, wenn der Benutzer zu diesem Schritt (oder zurück) gelangt. Ich beende mit step1_controller, step2_controller, etc ...
Option 2: Ich kann einen einzigen Controller erstellen und verfolgen, wo sie sich im Anmeldeprozess befinden, mit einem Parameter, einer Sitzungsvariablen, einer Zustandsmaschine - was auch immer. Also hätte ich signup_controller / step? Id = 1
Die erste Option ist streng REST, aber nicht sehr präzise und endet mit einigen zusätzlichen Controllern. Die zweite Option ist prägnanter, aber bricht REST, was ich will, aber ich nehme es nicht leicht.
Gibt es eine bessere Option?
Ich arbeite in Ruby auf Rails, aber diese Frage gilt für andere MVC-Implementierungen wie ASP.NET MVC
Ich bin eigentlich weniger darum besorgt, REST in einem One-Shot-Assistenten zu halten. REST ist sehr wichtig, denke ich, mit wiederholbaren Aktionen - Sie möchten, dass die URL im Prinzip mit einem Lesezeichen versehen werden kann, damit Sie die gleiche Ansicht der Daten erhalten, unabhängig davon, wann Sie dorthin gehen. In einem mehrstufigen Assistenten haben Sie Abhängigkeiten, die diese Perspektive von REST sowieso brechen. Mein Gefühl ist, einen einzelnen Controller mit möglicherweise separaten Aktionen zu haben oder Abfrageparameter zu verwenden, um anzuzeigen, auf welchem Schritt Sie sich befinden. So habe ich meine Aktivierungsassistenten (die mehrere Schritte erfordern) trotzdem strukturiert.
Wenn Sie hier eine DDD-Logik anwenden, die das "M" in MVC ergänzt, gehört der Status der Benutzeroberfläche (Registrierungsfortschritt) in die Anwendungsschicht, die direkt mit den Domänen- und Infrastruktur-Layern (vier Schichten: UI , Anwendung, Domäne und Infrastruktur). Das Konzept von DDD lässt Sie zunächst darüber nachdenken, wie Sie die Lösung im Code lösen können. Lass uns durchgehen ...
Der Status, den Sie hier pflegen möchten, ist der Schritt oder der Fortschritt der Registrierung. Mein erster Schritt wäre also, Fortschritte oder "Schritte" zu dokumentieren. Wie, Schritt 1: Get Benutzername / Pass, Schritt 2: E-Mail erhalten. In diesem Fall würde ich Logik anwenden, um das Modell zum nächsten Schritt zu bewegen. Höchstwahrscheinlich mit einer NextStep () - Methode auf einem RegistrationService (RegistrationService.NextStep ()).
Ich würde einen Dienst in der Anwendungsschicht namens RegistrationService erstellen. Ich würde hier eine Methode namens NextStep () platzieren. Aber denken Sie daran, die Domain würde den Zustand des Modells hier nicht halten. In diesem Fall sollten Sie den Status auf die Anwendungsschicht fokussieren. In diesem Fall würde NextStep () nicht auf ein Modellobjekt (da es nicht Teil der Domänenverantwortung ist) sondern auf die UI einwirken. Sie benötigen also etwas, um den Status des Registrierungsprozesses beizubehalten.
Nun wissen wir, dass wir den Status von etwas in der Benutzeroberfläche beibehalten müssen. MVC ermöglicht ein Konzept namens ViewModels (in ASP.NET MVC, nicht sicher, was RoR es nennt). Ein ViewModel stellt das Modell dar, das von der Ansicht und / oder Teilansichten angezeigt wird.
Das ViewModel wäre ein ausgezeichneter Ort, um den Zustand dieses Objekts zu speichern. Nennen wir es RegistrationProgressViewModel () und kleben eine NextStep () Methode darauf. Dies bedeutet natürlich, dass die Anwendungsschicht den Speicherort von RegistrationProgressViewModel beibehalten muss, und die APplication-Ebene die Interna davon basierend auf NextStep-Aktionen ändern würde. Wenn es komplex ist, möchten Sie vielleicht einen RegistrationProgressService () in der Anwendungsschicht erstellen und den NextStep () darin platzieren, um Ihre Logik wegzuspalten.
Das letzte Stück ist, wie man den Zustand dieses Objekts verfolgt. Da Webanwendungen staatenlos sind, müssen Sie die Kontrolle über andere Mittel als die Anwendung behalten. In diesem Fall würde ich entweder zu 1) Serialisierung des ViewModels zu dem Client zurückkehren und es dem Client hin und her geben lassen, oder 2) eine serverseitige Kopie des ViewModels behalten und einen Typ von Identifizierer hin und her übertragen zum Kunden und zurück.
Dies ist ein gutes Beispiel, um darüber nachzudenken, da ich das selbst noch nicht durchgeführt habe. Für # 2 ist der sicherste und sicherste Weg, den Zustand dieses ViewModel zu sichern, es über die Infrastruktur-Ebene beizubehalten (ja, der APp-Layer kann direkt mit der Infrastruktur-Ebene kommunizieren). Das scheint mir eine Menge Arbeit zu sein, für etwas, das vielleicht absterben wird und ich würde Teilregistrierungen in meiner Datenbank haben.
Aber # 2 würde die privaten Informationen (Benutzername, Passwort, E-Mail, CC # usw.) des Benutzers auf der Serverseite behalten und nicht vor und zurück weitergeben.
Also, nachdem wir hindurchgegangen waren, kamen wir auf:
Auf diese Weise müssen Sie niemals die "step? id = 2" in der View oder der Benutzeroberfläche selbst verfolgen, da das ViewModel aktualisiert und aktualisiert wird (Authenticated, Verified, persistent in DB), während Sie weitermachen.
Ihr nächstes Anliegen wäre also, in der Benutzeroberfläche "vorwärts zu gehen". Dies kann leicht mit einem Controller unter Verwendung von Schritten oder benannten Schritten durchgeführt werden.
Ich entschuldige mich, aber ich schreibe C # -Code unten, da das meine Sprache ist.
%Vor%Sie werden feststellen, dass dies die "Geschäftslogik" der Überprüfung des internen Zustands des Modells in die Methode "RegistrationProcessService.NextStep ()" abstrahiert.
Gute Übung. :)
Am Ende ist Ihre "RESTful" -URL ein nettes und sauberes POST an: / register, das ein ViewModel mit bestimmten Eigenschaften erwartet. Wenn das ViewModel nicht gültig ist, fährt / register nicht mit dem nächsten Schritt fort.
Obwohl die Antworten sehr nette Optionen sind, verwende ich immer noch den Ansatz, der in:
gegeben istShoulders of Giants | Ein RESTful-Assistent, der ASP.Net MVC verwendet .
Es ist definitiv einen Blick wert. Obwohl ich sagen muss, die Antworten, die hier gegeben werden, lassen mich denken, diesen Zauberer neu zu machen, wenn ich die Zeit habe.
Tags und Links asp.net-mvc ruby-on-rails model-view-controller rest