Auch wenn ich Alternativen zu PUT und DELETE anbiete (vgl. "Low REST"), wie kann ich benutzerfreundliche Formularvalidierung für Benutzer bereitstellen, die über den Browser auf meinen Webdienst zugreifen und trotzdem RESTful URIs anzeigen? Das Formularvalidierungsproblem (unten beschrieben) ist meine derzeitige Quandry, aber die umfassendere Frage, die ich stellen möchte, ist: wenn ich den Pfad versuche, sowohl eine REST-konforme öffentliche Schnittstelle als auch ein Nicht-Javascript bereitzustellen HTML-Schnittstelle, wird es das Leben leichter oder schwerer machen? Spielen sie überhaupt zusammen?
Theoretisch sollte es nur darum gehen, das Ausgabeformat zu variieren. Ein Computer kann die URL "/ people" abfragen und eine Liste von Personen in XML abrufen. Ein menschlicher Benutzer kann seinen Browser auf dieselbe URL verweisen und stattdessen eine hübsche HTML-Antwort erhalten. (Ich verwende die URL-Beispiele aus dem Mikroformat-Wiki , die ziemlich vernünftig erscheinen).
Das Erstellen einer neuen Personenressource erfolgt mit einer POST-Anfrage an die URL "/ people". Um dies zu erreichen, kann der Benutzer zuerst "/ people / new" aufrufen, was ein statisches HTML-Formular zum Erstellen der Ressource zurückgibt. Das Formular hat method = POST und action="/ people". Das funktioniert gut, wenn die Eingabe des Benutzers gültig ist. Was aber, wenn wir die Überprüfung auf der Serverseite durchführen und einen Fehler entdecken? Die freundliche Sache wäre, das Formular zurückzusenden, das mit den Daten gefüllt ist, die der Benutzer gerade eingegeben hat, plus eine Fehlermeldung, damit sie das Problem beheben und erneut einreichen können. Aber wir können diese Ausgabe nicht direkt von einem POST an "/ people" zurückgeben oder es bricht unser URL-System, und wenn wir den Benutzer zurück zum "/ people / new" -Formular umleiten, gibt es keine Möglichkeit, den Fehler zu melden und Füllen Sie das Formular erneut aus (es sei denn, wir speichern die Daten im Sitzungszustand, was noch weniger RESTful wäre).
Mit Javascript wären die Dinge viel einfacher. Führen Sie den POST einfach im Hintergrund aus, und wenn dies fehlschlägt, zeigen Sie den Fehler am oberen Rand des Formulars an. Aber ich möchte, dass die App ordnungsgemäß abwertet, wenn JavaScript-Unterstützung nicht verfügbar ist. Im Moment bin ich zu dem Schluss gekommen, dass eine nicht-triviale Web-App keine HTML-Schnittstelle ohne JavaScript implementieren kann, und ein konventionelles RESTful-URL-Schema verwenden (wie das im Wiki für Mikroformate beschrieben). Wenn ich falsch liege, sag es mir bitte!
Verwandte Fragen zu Stack Overflow (von denen sich keiner mit der Formularvalidierung befasst):
Sie könnten das HTML-Formular direkt an / people / new senden lassen. Wenn die Validierung fehlschlägt, geben Sie das Bearbeitungsformular mit den entsprechenden Informationen erneut ein. Wenn es erfolgreich ist, leiten Sie den Benutzer an die neue URL weiter. Dies würde mit der REST-Architektur übereinstimmen, wie ich sie verstehe.
Ich habe gesehen, wie Sie Monis Iqbal kommentiert haben, und ich muss zugeben, dass ich nicht weiß, was Sie mit "nicht-RESTful URLs" meinen. Das einzige, was die REST-Architektur von einer URL verlangt, ist, dass sie undurchsichtig ist und dass sie eindeutig mit einer Ressource gepaart ist. REST ist es egal, wie es aussieht, was darin enthalten ist, wie Schrägstriche oder verwendet, wie viele verwendet werden oder ähnliches. Das sichtbare Design der URL liegt bei Ihnen und REST hat keine Bedeutung.
Warum möchten Sie eine zweite "API" mit XML erstellen?
Ihr HTML enthält die Daten, die Ihr Benutzer sehen muss. HTML ist relativ einfach zu analysieren. Das Klassenattribut kann verwendet werden, um Semantik wie Mikroformate hinzuzufügen. Ihr HTML enthält Formulare und Links, um auf alle Funktionen Ihrer Anwendung zugreifen zu können.
Warum würden Sie eine andere Schnittstelle schaffen, die komplett semantisch freie Anwendung / XML liefert, die wahrscheinlich keine Hypermedia-Links enthält, so dass Sie jetzt URLs in Ihren Client hart codieren müssen, was zu einer unangenehmen Kopplung führt?
Wenn Sie Ihre Anwendung mithilfe von HTML in einem Webbrowser ausführen können, ohne den Sitzungsstatus speichern zu müssen, verfügen Sie bereits über eine RESTful-API. Töte dich nicht dabei, einen Haufen URLs zu entwerfen, die der Idee eines Standards entsprechen.
Hier ist ein Zitat von Roy Fielding,
>Eine REST-API darf nicht fix definiert sein Ressourcennamen oder -hierarchien
Ich weiß, dass dies angesichts fast aller REST-Beispiele, die Sie gesehen haben, ins Rollen kommt, aber das liegt daran, dass sie alle falsch liegen. Ich weiß, dass ich anfange, wie ein religiöser Eiferer zu klingen, aber es bringt mich um, Leute zu sehen, die darum kämpfen, REST-konforme APIs zu entwickeln, wenn sie völlig falsch anfangen.
Höre Breton zu, wenn er sagt: "REST ist egal, wie [die URL] aussieht" und @Wahnfrieden wird bald kommen, um dir dasselbe zu sagen. Diese Mikroformat-Seite ist ein schrecklicher Ratschlag für jemanden, der versucht REST zu machen. Ich sage nicht, dass es ein schrecklicher Ratschlag für jemanden ist, der eine andere Art von HTTP-API erstellt, nur keine REST-konforme.
Danke für die Antworten. Sie haben meine Gedanken ein wenig befreit, und so möchte ich als Antwort auf meine eigene Frage eine alternative Reihe von RESTful URL-Konventionen vorschlagen, die die beiden Methoden (GET und POST) der Nicht-AJAX-Welt, anstatt zu versuchen, sie zu umgehen.
Bearbeiten: Wie Kommentatoren hervorgehoben haben, sollten diese "Konventionen" nicht Teil der RESTful-API selbst sein. Auf der anderen Seite sind interne Konventionen nützlich, da sie die serverseitige Implementierung konsistenter machen und somit für Entwickler einfacher zu verstehen und zu warten sind. REST-konforme Clients sollten die URLs jedoch als undurchsichtig behandeln und sie immer als Hyperlinks abrufen, niemals durch selbst erstellte URLs.
GET / Leute
eine Liste aller Datensätze zurückgeben mit GET / people / new
ein Formular zum Hinzufügen eines neuen Datensatzes zurückgeben POST / people / new
erstelle einen neuen Rekord
(Für einen HTML-Client, geben Sie das Formular erneut zurück, wenn die Eingabe ungültig ist, andernfalls leiten Sie es an die neue Ressource weiter)
GET / people / 1
den ersten Datensatz zurückgeben
GET / people / 1 / bearbeiten
Rückgabe eines Formulars zum Bearbeiten des ersten Datensatzes
POST / people / 1 / bearbeiten
Aktualisiere den ersten Datensatz
GET / people / 1 / delete
ein Formular zum Löschen des Datensatzes zurückgeben
(kann einfach eine Bestätigung sein - Möchten Sie wirklich löschen?)
POST / Personen / 1 / löschen
Löschen Sie den Datensatz
Hier gibt es ein Muster: GET auf eine Ressource, z.B. "/ people / 1", gibt den Datensatz selbst zurück. GET auf Ressource + Operation gibt ein HTML-Formular zurück, z. "/ Personen / 1 / bearbeiten". POST bei der Operation ressource + führt die Operation tatsächlich aus.
Vielleicht ist das nicht so elegant wie die Verwendung zusätzlicher HTTP-Verben (PUT und DELETE), aber diese URLs sollten gut mit Vanilla-HTML-Formularen funktionieren. Sie sollten auch für einen menschlichen Benutzer ziemlich selbsterklärend sein ... Ich glaube an die Idee, dass "die URL ein Teil der Benutzeroberfläche ist" für Benutzer, die über einen Browser auf den Webserver zugreifen.
P.S. Lass mich erklären, wie ich die Löschungen machen würde. Die Ansicht "/ people / 1" enthält einen Link zu "/ people / 1 / delete" mit einem Onclick-JavaScript-Handler. Wenn JavaScript aktiviert ist, wird der Klick abgefangen und dem Benutzer ein Bestätigungsfeld angezeigt. Wenn sie das Löschen bestätigen, wird ein POST gesendet, der den Datensatz sofort löscht. Wenn JavaScript jedoch deaktiviert ist, wird beim Klicken auf den Link stattdessen eine GET-Anforderung gesendet, die ein Löschbestätigungsformular vom Server zurückgibt, und das Formular das sendet den POST zum Ausführen des Löschvorgangs. So verbessert Javascript die Benutzererfahrung (schnellere Reaktion), aber ohne sie verschlechtert sich die Website anmutig.
Warum nicht AJAX verwenden, um die Arbeit auf der Client-Seite zu tun, und wenn Javascript deaktiviert ist, dann entwerfe das HTML so, dass der konventionelle POST funktioniert.