it-swarm.com.de

Richtige Route zum Überprüfen der Existenz von Ressourcen in einer RESTful-API

Was ist der beste/erholsamste Weg, um einen API-Endpunkt zum Überprüfen der Existenz von Ressourcen zu entwerfen?

Zum Beispiel gibt es eine Benutzerdatenbank. Während der neue Benutzer versucht, sich anzumelden, möchte ich prüfen, ob die E-Mail direkt verwendet wurde.

Meine Idee ist: POST /user/exists und die Nutzlast wäre so etwas wie {"email": "[email protected]"}. Die Antwort wäre entweder 200 OK oder 409 Conflict.

Ist das ein richtiger Weg?

Vielen Dank!

25
x1a0

HEAD ist am effektivsten für Existenzprüfungen:

HEAD /users/{username}

Fordern Sie den Pfad eines Benutzers an und geben Sie einen 200 zurück, falls er existiert, oder einen 404, falls dies nicht der Fall ist.

Allerdings möchten Sie wahrscheinlich keine Endpunkte verfügbar machen, die E-Mail-Adressen prüfen. Es öffnet sich eine Sicherheits- und Datenschutzlücke. Benutzernamen, die bereits öffentlich auf einer Website angezeigt werden, wie zum Beispiel bei reddit, könnten in Ordnung sein.

20
Baz

Ich glaube, der beste Weg, einfach nach Existenz zu suchen, besteht darin, ein HEAD-Verb für jede Ressource zu verwenden, die Sie normalerweise mit einer GET-Anforderung erhalten würden.

Ich bin kürzlich auf eine Situation gestoßen, in der ich das Vorhandensein einer möglicherweise großen Videodatei auf dem Server überprüfen wollte. Ich wollte nicht, dass der Server versucht, die Bytes zu einem beliebigen Client zu streamen. Daher implementierte ich eine HEAD-Antwort, die nur die Header zurückgab, die der Client bei einer GET-Anforderung für dieses Video erhalten würde.

Sie können die W3-Spezifikation hier oder Lesen diesen Blogbeitrag über die praktische Verwendung des HEAD-Verbs überprüfen.

Ich finde das großartig, weil Sie nicht darüber nachdenken müssen, wie Sie Ihre Route anders als bei einer normalen RESTful-Route gestalten müssen, um zu prüfen, ob eine Ressource vorhanden ist. Dies kann eine Datei oder eine typische Ressource sein, z. B. ein Benutzer oder etwas.

5
arjabbar
GET /[email protected]

Dies ist eine einfache Suchabfrage: Finden Sie die Benutzer mit der angegebenen E-Mail-Adresse. Antworten Sie mit einer leeren Sammlung, wenn keine Benutzer vorhanden sind, oder antworten Sie mit den Benutzern, die der Bedingung entsprechen.

3
Paul Turner

Ich bevorzuge:

HEAD /users/email/[email protected]

Erläuterung: Sie versuchen, durch alle Benutzer jemanden zu finden, der die E-Mail-Adresse [email protected] verwendet. Ich gehe hier davon aus, dass die E-Mail nicht der Schlüssel Ihrer Ressource ist, und Sie haben etwas Flexibilität, denn wenn Sie einen anderen Endpunkt benötigen, um die Verfügbarkeit anderer Informationen des Benutzers zu prüfen, kann dieser Ansatz passen sehr gut.

Als Antwort geben Sie 200 (falls nicht verfügbar) oder 404 (falls verfügbar) nur als http-Code-Antwort zurück.

Sie können auch verwenden:

HEAD /emails/[email protected]

wenn der HEAD /users/email/[email protected] mit einer vorhandenen Restressource kollidiert, beispielsweise einem GET /users/email/[email protected] mit einer anderen Geschäftsregel. Wie auf Mozillas Dokumentation beschrieben :

Die Methode HEAD fragt nach einer Antwort, die mit der einer GET-Anfrage identisch ist, jedoch ohne den Antworttext. *. 

Also, GET und HEAD mit unterschiedlichen Regeln sind nicht gut.

Ein HEAD /users/[email protected] ist auch eine gute Option, wenn die E-Mail der "Schlüssel" der users ist, weil Sie (wahrscheinlich) einen GET /users/[email protected] haben.

1
Dherik