Empfohlener HTTP-Statuscode für die Antwort "Planlimit überschritten"

Ich entwerfe eine REST-API für ein Projekt, in dem Benutzer immer einen von mehreren "Plänen" verwenden. Jeder Plan definiert einige Ressourcenbegrenzungen, z. B. die maximale Anzahl von Benutzern, die ein Konto haben darf, oder die maximale Anzahl von Daten, die sie hochladen dürfen. Sobald eines dieser Limits erreicht ist, können Benutzer ihre Pläne aktualisieren (im Wesentlichen bezahlen), um mehr Ressourcen zu erhalten.

Ich möchte einen speziellen Statuscode zurückgeben, der auf eine Situation hinweist, in der die Aktion aufgrund von Kontoressourcenbeschränkungen nicht ausgeführt werden kann, und das Aktualisieren des Plans behebt diesen Fehler, z. B. wenn ein Benutzer 100% seiner Speicherkapazität verwendet und versucht, eine zusätzliche Datei hochzuladen Sie werden diese Antwort erhalten.

Die Kandidaten sind, IMHO:

• 403 Forbidden - Ich möchte jedoch zwischen diesem Fall und anderen Fällen unterscheiden, in denen dem Benutzer einfach die Berechtigung zum Ausführen dieser Aktion fehlt.

• 401 Unauthorized - Keine gute Idee, wir verwenden dies für Authentifizierungsprobleme.

• 402 Payment Required - Sinnvoll, aber ich mache mir Sorgen über die Verwendung eines nicht standardmäßigen, aber reservierten Statuscodes

• Etwas noch weniger Standard wie es 423 Lockedunwahrscheinlich ist, dass wir es für irgendetwas anderes in der Zukunft verwenden werden

Eine andere Möglichkeit besteht darin, mit etwas sehr Standardmäßigem zu arbeiten, z. B. 403die Besonderheiten des Fehlers im Antworttext anzugeben.

Ich frage mich, welcher Ansatz Ihrer Meinung nach (a) auf lange Sicht am besten funktioniert und (b) sich besser an RESTful-Prinzipien hält.

Ich denke, 403 ist die einzig vernünftige Antwort, obwohl 405 Methode nicht erlaubt oder 409 Konflikt akzeptabel sein könnte, denke ich, dass beide nicht so gut sind wie 403, was besagt:

Der Server hat die Anfrage verstanden, lehnt sie jedoch ab. Die Autorisierung hilft nicht und die Anfrage SOLLTE NICHT wiederholt werden. Wenn die Anforderungsmethode nicht HEAD war und der Server veröffentlichen möchte, warum die Anforderung nicht erfüllt wurde, MUSS er den Grund für die Ablehnung in der Entität beschreiben

Wenn Sie einen 403-Fehler zurückgeben, werden einige Informationen dazu angezeigt, warum die Ressource abgelehnt wurde. Ungültige Berechtigungen sind nur der häufigste Fall. Überschrittene Grenzwerte unterscheiden sich nicht wesentlich. Sie haben keine Berechtigungen, da Ihr Grenzwert überschritten wurde.

Ich glaube, 403 ist falsch, weil 403 für Situationen gedacht ist, in denen Sie keinen Zugriff auf die Ressource erhalten und es überhaupt keine Möglichkeit gibt, Zugriff zu erhalten. Für Ihre Kunden gibt es offensichtlich eine Möglichkeit, Zugang zu erhalten: Zahlen Sie.

401 ist wirklich falsch, weil Sie es nicht nur zur Authentifizierung verwenden, sondern auch dafür.

Da Sie eine API schreiben, gehe ich davon aus, dass eine andere Person Code schreiben muss, der die API verwendet, und diese Person muss Ihre API-Spezifikation lesen. Sie könnten mit 429 "Zu viele Anfragen" gehen. Es ist normalerweise zur Preisbegrenzung gedacht (wo ein Kunde beispielsweise 100 Anfragen pro Tag stellen kann), trifft jedoch in angemessener Weise auf Ihre Situation zu. 402 (Zahlung erforderlich) wäre auch akzeptabel, denke ich. Hängt davon ab, mit welchen Tools die Benutzer Ihre API verwenden sollen. 429 hat das Risiko, dass ein cleveres Tool versucht, weniger Anfragen pro Minute / Stunde / Tag zu senden, was jedoch nie erfolgreich ist.

Übrigens, laut https://tools.ietf.org/html/rfc6585 sollte der Fehler 429 auch eine HTML-Nachricht enthalten, die die Art des Problems beschreibt, sodass die Wahrscheinlichkeit groß ist, dass dem Benutzer tatsächlich mitgeteilt wird, um welches Problem es sich handelt, wenn Sie etwas angeben diese Informationen in Ihrer Antwort.

WebDAV verwendet hierfür HTTP 507 Unzureichender Speicher und enthält einen zusätzlichen Fehlercode für das Kontingent, das im Anforderungshauptteil überschritten wurde, um es von anderen Arten von Speicherbeschränkungen zu unterscheiden.