Ich entwarf eine Web-App und überlegte dann, wie meine API als RESTful-Webdienst gestaltet werden sollte. Derzeit sind die meisten meiner URIs generisch und gelten möglicherweise für verschiedene Web-Apps:
GET /logout // destroys session and redirects to /
GET /login // gets the webpage that has the login form
POST /login // authenticates credentials against database and either redirects home with a new session or redirects back to /login
GET /register // gets the webpage that has the registration form
POST /register // records the entered information into database as a new /user/xxx
GET /user/xxx // gets and renders current user data in a profile view
POST /user/xxx // updates new information about user
Ich habe das Gefühl, dass ich hier viel falsch mache, nachdem ich mich bei SO und Google umgesehen habe.
Beginnen /logout
wir mit , vielleicht, weil ich eigentlich GET
nichts habe - es ist möglicherweise angemessener, POST
eine Anfrage zu stellen /logout
, die Sitzung zu zerstören und dann GET
umzuleiten. Und soll der /logout
Begriff bleiben?
Was ist mit /login
und /register
. Ich könnte zu ändern /register
, /registration
aber das ändert nichts an der grundsätzlichen Funktionsweise meines Dienstes - wenn er tiefere Probleme hat.
Ich bemerke jetzt, dass ich niemals eine /user
Ressource verfügbar mache. Vielleicht könnte das irgendwie genutzt werden. Nehmen Sie zum Beispiel den Benutzer myUser
:
foo.com/user/myUser
oder
foo.com/user
Der Endbenutzer benötigt diese zusätzliche Ausführlichkeit in der URI nicht. Welches ist jedoch optisch ansprechender?
Ich habe hier auf SO einige andere Fragen zu diesem REST-Geschäft bemerkt, aber ich würde mich sehr über eine Anleitung freuen, was ich hier dargelegt habe, wenn möglich.
Vielen Dank!
AKTUALISIEREN:
Ich hätte auch gerne einige Meinungen zu:
/user/1
vs.
/user/myUserName
quelle
Antworten:
Eines sticht insbesondere als nicht REST-voll heraus: die Verwendung einer GET-Anfrage zum Abmelden.
(von http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Safe_methods )
Beim Abmelden und Umleiten kann ein Beitrag zu Ihrem Abmelde-URI eine 303-Antwort geben, die zur Seite nach dem Abmelden umleitet.
http://en.wikipedia.org/wiki/Post/Redirect/Get
http://en.wikipedia.org/wiki/HTTP_303
Bearbeiten, um Bedenken hinsichtlich des URL-Designs auszuräumen:
"Wie gestalte ich meine Ressourcen?" ist eine wichtige Frage für mich; "Wie gestalte ich meine URLs?" ist eine Überlegung in zwei Bereichen:
URLs, die Benutzer sehen, sollten nach Möglichkeit nicht zu hässlich und aussagekräftig sein. Wenn Sie möchten, dass Cookies in Anfragen an eine Ressource gesendet werden, andere jedoch nicht, sollten Sie Ihre Pfade und Cookie-Pfade strukturieren.
Wenn Sie
JRandomUser
sich sein eigenes Profil ansehen möchten und die URL hübscher alsfoo.com/user/JRandomUser
oder sein sollfoo.com/user/(JRandom's numeric user id here)
, können Sie eine separate URL erstellen , damit ein Benutzer seine eigenen Informationen einsehen kann:Ich würde Unwissenheit in diesem Bereich viel leichter als Weisheit behaupten, aber hier sind einige Überlegungen zum Ressourcendesign:
quelle
GET foo.com/profile/
) implementieren würde, wäre das Teil der Präsentationsschicht, wie Momo vorgeschlagen hat? Mit anderen Worten, was genau sollte dieseGET
Anfrage zurückgeben? Eine Webseite oder ein JSON?GET
,POST
,PUT
, undDELETE
Ressourcen. Eine Website ist nur eine weitere Plattform, die auf die API zugreift. Mit anderen Worten, das Website-URL-Design unterscheidet sich grundlegend vom RESTful-API-Design. Bitte sag mir, ob ich immer noch falsch liege, haha.RESTful kann als Richtlinie zum Erstellen von URLs verwendet werden, und Sie können Sitzungen und Benutzerressourcen erstellen:
GET /session/new
Ruft die Webseite mit dem Anmeldeformular abPOST /session
authentifiziert Anmeldeinformationen anhand der DatenbankDELETE /session
zerstört die Sitzung und leitet zu / umGET /users/new
Ruft die Webseite mit dem Registrierungsformular abPOST /users
Zeichnet die eingegebenen Informationen als neuen / user / xxx in der Datenbank aufGET /users/xxx
// ruft aktuelle Benutzerdaten in einer Profilansicht ab und rendert siePOST /users/xxx
// aktualisiert neue Informationen über den BenutzerDiese können Plural oder Singular sein (ich bin mir nicht sicher, welches richtig ist). Ich habe normalerweise
/users
für eine Benutzerindexseite (wie erwartet) verwendet, um/sessions
zu sehen, wer angemeldet ist (wie erwartet).Die Verwendung des Namens in der URL anstelle einer Zahl (
/users/43
vs./users/joe
) beruht normalerweise auf dem Wunsch, den Benutzern oder Suchmaschinen gegenüber freundlicher zu sein, und nicht auf technischen Anforderungen. Beides ist in Ordnung, aber ich würde empfehlen, dass Sie konsequent sind.Ich denke, wenn Sie mit dem Registrieren / Anmelden / Abmelden gehen oder
sign(in|up|out)
, funktioniert es nicht so gut mit der erholsamen Terminologie.quelle
/new
anGET /session/
nicht RESTful angehängt wird? Ich habe gehört , dass die Verben auf die HTTP - Verben typischerweise links sind (GET
,POST
usw.).Sitzungen sind nicht RESTful
Ja, ich weiß. Es wird normalerweise mit OAuth durchgeführt, aber Sitzungen sind wirklich nicht RESTful. Sie sollten in erster Linie keine / login / logout-Ressource haben, da Sie keine Sitzungen haben sollten.
Wenn Sie es tun wollen, machen Sie es RESTful. Ressourcen sind Substantive und / login und / logout sind keine Substantive. Ich würde mit / Sitzung gehen. Dies macht das Erstellen und Löschen zu einer natürlicheren Aktion.
POST vs. GET für Sitzungen ist einfach. Wenn Sie Benutzer / Passwort als Variablen senden, würde ich POST verwenden, da ich nicht möchte, dass das Passwort als Teil des URI gesendet wird. Es wird in Protokollen angezeigt und möglicherweise über dem Draht freigelegt. Sie laufen auch Gefahr, dass Software aufgrund der Einschränkungen von GET args ausfällt.
Ich verwende im Allgemeinen Basic Auth oder kein Auth mit REST-Diensten.
Benutzer erstellen
Es ist eine Ressource, daher sollten Sie sich nicht registrieren.
Welche Art von ID zu verwenden ist, ist eine schwierige Frage. Sie müssen darüber nachdenken, die Eindeutigkeit durchzusetzen und alte IDs wiederzuverwenden, die gelöscht wurden. Beispielsweise möchten Sie diese IDs nicht als Fremdschlüssel in einem Backend verwenden, wenn IDs recycelt werden sollen (sofern dies überhaupt möglich ist). Sie können jedoch nach externen / internen ID-Konvertierungen suchen, um die Backend-Anforderungen zu verringern.
quelle
Ich werde einfach aus meiner Erfahrung mit der Integration verschiedener REST-Webdienste für meine Kunden sprechen, sei es für mobile Apps oder für die Server-zu-Server-Kommunikation sowie für die Erstellung der REST-API für andere. Hier sind einige Beobachtungen, die ich aus der REST-API anderer Leute sowie aus denen, die wir selbst erstellt haben, gesammelt habe:
Da REST als Services konzipiert sind, geben Funktionen wie Anmelden und Abmelden normalerweise Erfolgs- / Fehlerergebnisse zurück (normalerweise im JSON- oder XML-Datenformat), die der Verbraucher dann interpretieren würde. Eine solche Interpretation könnte die Weiterleitung auf eine geeignete Webseite umfassen, wie Sie erwähnt haben
Das sind einige Punkte von dem, was ich behandelt habe. Ich hoffe, es könnte Ihnen einige Einblicke geben.
Was nun die Implementierung Ihres REST betrifft, so sind dies die typischen Implementierungen, auf die ich gestoßen bin:
Führen Sie die Abmeldung im Backend aus und geben Sie JSON zurück, um den Erfolg / Misserfolg des Vorgangs anzuzeigen
Senden Sie Ihre Anmeldeinformationen an das Backend. Erfolg / Misserfolg zurückgeben. Bei Erfolg werden normalerweise auch das Sitzungstoken sowie die Profilinformationen zurückgegeben.
Senden Sie die Registrierung an das Backend. Erfolg / Misserfolg zurückgeben. Wenn dies erfolgreich ist, wird dies normalerweise genauso behandelt wie eine erfolgreiche Anmeldung, oder Sie können die Registrierung als eigenständigen Dienst vornehmen
Benutzerprofil abrufen und JSON-Datenformat für das Benutzerprofil zurückgeben
Veröffentlichen Sie aktualisierte Profilinformationen im JSON-Format und aktualisieren Sie die Informationen im Backend. Erfolg / Misserfolg an den Anrufer zurückgeben
quelle
Ich glaube, dies ist ein RESTful-Ansatz zur Authentifizierung. Für LogIn verwenden Sie
HttpPut
. Diese HTTP-Methode kann zur Erstellung verwendet werden, wenn der Schlüssel bereitgestellt wird und wiederholte Aufrufe idempotent sind. Für LogOff geben Sie denselben Pfad unter derHttpDelete
Methode an. Keine Verben verwendet. Richtige Sammlungspluralisierung. Die HTTP-Methoden unterstützen den Zweck.Falls gewünscht, können Sie den aktiven Strom ersetzen.
quelle
Ich würde empfehlen, eine Benutzerkonto-URL zu verwenden, die Twitter ähnelt, wobei die URL des Benutzerkontos so aussieht, als
foo.com/myUserName
könnten Sie mit der URL https://twitter.com/joelbyler zu meinem Twitter-Konto gelangenIch bin nicht einverstanden, dass für die Abmeldung ein POST erforderlich ist. Wenn Sie als Teil Ihrer API eine Sitzung verwalten möchten, kann eine Sitzungs-ID in Form einer UUID verwendet werden, um den Überblick über einen Benutzer zu behalten und zu bestätigen, dass die ausgeführte Aktion autorisiert ist. Dann kann sogar ein GET die Sitzungs-ID an die Ressource weitergeben.
Kurz gesagt, ich würde empfehlen, dass Sie es einfach halten, URLs sollten kurz und einprägsam sein.
quelle