Ressourcen neu gestalten, anmelden oder registrieren?

RESTful kann als Richtlinie zum Erstellen von URLs verwendet werden, und Sie können sessions und sers Ressourcen erstellen:

• GET /session/new Ruft die Webseite mit dem Anmeldeformular auf
• POST /session Authentifiziert Anmeldeinformationen für die Datenbank
• DELETE /session Zerstört die Sitzung und leitet zu/weiter
• GET /users/new Ruft die Webseite mit dem Registrierungsformular auf
• POST /users Zeichnet die eingegebenen Informationen als new/user/xxx in der Datenbank auf
• GET /users/xxx // holt und rendert aktuelle Benutzerdaten in einer Profilansicht
• POST /users/xxx // aktualisiert neue Informationen zum Benutzer

Diese können im Plural oder im Singular sein (ich bin mir nicht sicher, welches richtig ist). Ich habe normalerweise /users Für eine Benutzerindexseite (wie erwartet) und /sessions Verwendet, um zu sehen, wer (wie erwartet) angemeldet ist.

Die Verwendung des Namens in der URL anstelle einer Zahl (/users/43 Vs. /users/joe) Wird normalerweise von dem Wunsch getrieben, den Benutzern oder Suchmaschinen freundlicher zu sein, und nicht von technischen Anforderungen. Beides ist in Ordnung, aber ich würde empfehlen, dass Sie konsequent sind.

Ich denke, wenn Sie mit dem Register/Login/Logout oder sign(in|up|out) gehen, funktioniert es nicht so gut mit der Restful-Terminologie.

Sitzungen sind nicht RESTful

• Ja, ich weiß. Es wird normalerweise mit OAuth gemacht, aber wirklich sind Sitzungen nicht RESTful. Sie sollten keine/login/logout-Ressource haben, da Sie keine Sitzungen haben sollten.

• Wenn Sie es tun wollen, machen Sie es RUHIG. Ressourcen sind Substantive und/login und/logout sind keine Substantive. Ich würde mit/Sitzung gehen. Dadurch wird das Erstellen und Löschen natürlicher.

• POST vs. GET für Sitzungen ist einfach. Wenn Sie Benutzer/Kennwort als Variablen senden, würde ich POST verwenden, da ich das Kennwort nicht als Teil der URI senden lassen möchte. Es wird in Protokollen angezeigt und möglicherweise angezeigt Sie laufen auch Gefahr, dass Software aufgrund von GET-Einschränkungen ausfällt.

• Ich verwende im Allgemeinen Basic Auth oder kein Auth mit REST Services.

Benutzer anlegen

• Es ist eine Ressource, daher sollten Sie sich nicht registrieren müssen.

  • POST/Benutzer - Erstellt einen Benutzer, wenn der Anforderer die ID nicht angeben kann
  • PUT/user/xxx - Erstellt oder aktualisiert einen Benutzer, vorausgesetzt, Sie kennen die ID im Voraus
  • GET/user - listet x Benutzer-IDs auf
  • GET/user/xxx - Ruft die Details des Benutzers mit der ID xxx ab
  • DELETE/user/xxx - Löscht den Benutzer mit der ID xxx

• Welche Art von ID zu verwenden ist, ist eine schwierige Frage. Sie müssen darüber nachdenken, Eindeutigkeit zu erzwingen und alte IDs, die DELETEd waren, wiederzuverwenden. Beispielsweise möchten Sie diese IDs nicht als Fremdschlüssel in einem Backend verwenden, wenn IDs wiederverwendet werden sollen (sofern dies überhaupt möglich ist). Sie können jedoch nach einer externen/internen ID-Konvertierung suchen, um die Backend-Anforderungen zu verringern.

Ich spreche einfach aus meiner Erfahrung mit der Integration verschiedener REST Web Services für meine Kunden, sei es für mobile Apps oder für die Server-zu-Server-Kommunikation sowie für die Erstellung von REST APIs für Andere. Hier sind einige Beobachtungen, die ich aus der API REST anderer Personen sowie aus den von uns selbst erstellten gesammelt habe:

• Wenn wir API sagen, bezieht es sich normalerweise auf eine Reihe von Programmierschnittstellen und nicht auf die Präsentationsschicht. REST ist auch datenzentriert und nicht präsentationsgesteuert. Das heißt, die meisten REST geben Daten in Form von JSON oder XML zurück und geben selten eine bestimmte Präsentationsebene zurück. Diese Eigenschaft (das Zurückgeben von Daten und nicht die direkte Webseite) setzt die REST Fähigkeit voraus, eine Mehrkanal-Zustellung durchzuführen. Dies bedeutet, dass derselbe Webservice in HTML, iOS, Android oder sogar als Server-zu-Server-Kombination dargestellt werden kann.
• Es ist sehr selten, HTML und REST als URL zu kombinieren. Standardmäßig sind REST Gedanken als Services und haben keine Präsentationsebene. Es ist die Aufgabe derjenigen, die die Webservices nutzen, die Daten der von ihnen aufgerufenen Services nach ihren Wünschen wiederzugeben. Bis zu diesem Punkt stimmt Ihre unten stehende URL nicht mit den meisten REST - basierten Designs überein, auf die ich bisher gestoßen bin (auch nicht mit den Standards, die von Facebook oder Twitter stammen).

 GET/register // ruft die Webseite mit dem Registrierungsformular auf 

• Weiter vom vorherigen Punkt aus ist es auch ungewöhnlich (und ich bin nicht darauf gestoßen), dass ein REST - basierter Service eine Umleitung durchführt, wie die unten vorgeschlagenen:

 GET/logout // löscht die Sitzung und leitet sie zu /[.____.)POST/login // authentifiziert die Anmeldeinformationen für die Datenbank und leitet sie entweder mit einer neuen Sitzung nach Hause weiter oder leitet sie zurück zu /login[.____] 

Da REST als Dienste konzipiert sind, liefern Funktionen wie Anmelden und Abmelden normalerweise Erfolgs-/Fehlerergebnisse (normalerweise im JSON- oder XML-Datenformat), die dann vom Konsumenten interpretiert werden. Eine solche Interpretation könnte die von Ihnen erwähnte Weiterleitung zu einer geeigneten Webseite beinhalten

• In REST gibt die URL die durchgeführten Aktionen an. Aus diesem Grund sollten wir so viele Unklarheiten wie möglich beseitigen. In Ihrem Fall ist es zwar legitim, sowohl GET als auch POST mit demselben Pfad (z. B./register) zu verwenden, die unterschiedliche Aktionen ausführen. Ein solches Design führt jedoch zu Mehrdeutigkeiten bei den bereitgestellten Diensten und kann den Verbraucher Ihrer Dienste verwirren . Zum Beispiel sind die URLs, wie die, die Sie unten einführen, nicht ideal für REST basierte Services

 GET/register // ruft die Webseite mit dem Registrierungsformular auf 
 POST/register // speichert die eingegebenen Informationen in der Datenbank als neues /user/xxx

Das sind einige Punkte aus dem, was ich behandelt habe. Ich hoffe, es hat Ihnen einige Einblicke verschafft.

Was die Implementierung Ihres REST angeht, sind dies die typischen Implementierungen, auf die ich gestoßen bin:

•  GET/logout 
  

  Führen Sie die Abmeldung im Backend aus und geben Sie JSON zurück, um den Erfolg/Misserfolg der Operation anzuzeigen

•  POST /login
  

  Übermitteln Sie die Anmeldeinformationen an das Backend. Erfolg/Misserfolg zurückgeben. Bei Erfolg werden normalerweise auch das Sitzungstoken sowie die Profilinformationen zurückgegeben.

•  POST/register
  

  Senden Sie die Registrierung an das Backend. Erfolg/Misserfolg zurückgeben. Wenn dies erfolgreich ist, wird dies normalerweise als erfolgreiche Anmeldung behandelt, oder Sie können die Registrierung als eigenständigen Dienst vornehmen

•  GET /user/xxx
  

  Benutzerprofil abrufen und JSON-Datenformat für das Benutzerprofil zurückgeben

•  POST/user/xxx 
   // umbenannt in 
   POST /updateUser/xxx
  

  Veröffentlichen Sie aktualisierte Profilinformationen im JSON-Format und aktualisieren Sie die Informationen im Backend. Rückgabe von Erfolg/Misserfolg an den Anrufer

Ich glaube, dies ist ein restvoller Ansatz zur Authentifizierung. Für LogIn verwenden Sie HttpPut. Diese HTTP-Methode kann zur Erstellung verwendet werden, wenn der Schlüssel bereitgestellt wird. Wiederholte Anrufe sind idempotent. Für LogOff geben Sie denselben Pfad unter der Methode HttpDelete an. Keine Verben verwendet. Ordnungsgemäße Pluralisierung von Sammlungen. Die HTTP-Methoden unterstützen den Zweck.

[HttpPut]
[Route("sessions/current")]
public IActionResult LogIn(LogInModel model) { ... }

[HttpDelete]
[Route("sessions/current")]
public IActionResult LogOff() { ... }

Falls gewünscht, können Sie aktiv durch Strom ersetzen.

Ich würde empfehlen, eine Benutzerkonto-URL zu verwenden, die der von Twitter ähnelt, wobei die Benutzerkonto-URL etwa foo.com/myUserName so wie Sie mit der URL zu meinem Twitter-Account gelangen können https://Twitter.com/joelbyler

Ich bin nicht einverstanden, dass ich mich abmelden muss, wenn ich einen POST benötige. 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 übergeben.

Kurz gesagt, ich würde empfehlen, dass Sie es einfach halten, URLs sollten kurz und einprägsam sein.