Code d'état HTTP REST suggéré pour "limite de demande atteinte"

Je suis en train de mettre au point une spécification pour un service REST, qui inclura une partie de la capacité de limiter les utilisateurs à l’échelle du service et à des groupes de ressources ou sur des ressources individuelles. De même, les délais d'attente pour ceux-ci seraient configurables par ressource / groupe / service.

Je regarde juste à travers les spécifications HTTP 1.1 et j'essaie de décider comment je vais communiquer à un client qu'une demande ne sera pas satisfaite car ils ont atteint leur limite.

Initialement, je pensais que le code client 403 - Forbiddenétait celui-là, mais ceci, de la spécification:

L'autorisation n'aidera pas et la demande NE DEVRAIT PAS être répétée

m'a ennuyé.

En fait, il semble que ce 503 - Service Unavailablesoit meilleur à utiliser - car cela permet la communication d’un temps de nouvelle tentative grâce à l’utilisation de l’en- Retry-Aftertête.

Il est possible que, dans le futur, je puisse envisager de prendre en charge davantage de demandes d'achat via le commerce électronique (dans ce cas, ce serait bien si le code client 402 - Payment Requiredavait été finalisé!) - mais je pense que cela pourrait également être inséré dans une réponse 503.

Lequel pensez-vous que je devrais utiliser? Ou y a-t-il un autre que je n'ai pas considéré?

web-services rest http

— Andras Zoltan
source

Réponses:

429 Trop de demandes

L'utilisateur a envoyé trop de demandes dans un laps de temps donné. Destiné à être utilisé avec des systèmes de limitation de débit. Ce code a été accepté dans la RFC 6585 Codes d’état HTTP supplémentaires .

   The 429 status code indicates that the user has sent too many
   requests in a given amount of time ("rate limiting").

   The response representations SHOULD include details explaining the
   condition, and MAY include a Retry-After header indicating how long
   to wait before making a new request...

   Note that this specification does not define how the origin server
   identifies the user, nor how it counts requests.  For example, an
   origin server that is limiting request rates can do so based upon
   counts of requests on a per-resource basis, across the entire server,
   or even among a set of servers.  Likewise, it might identify the user
   by its authentication credentials, or a stateful cookie.

   Responses with the 429 status code MUST NOT be stored by a cache...

— Sean McMillan
source

Cela semble génial - je vais le garder à l'esprit! Vient-il avec des chats gratuits? Ou sont-ils une extension du protocole?

— Andras Zoltan

HTTP Status cats - pour tous vos besoins en matière de statut: flickr.com/photos/girliemac/sets/72157628409467125

— Sean McMillan le

ça vient de faire le tour du bureau avec beaucoup de rires et d'applaudissements - génie!

— Andras Zoltan

Je suis allé avec un 429 à la fin - c'est dans le brouillon mais je doute fort qu'il finisse par être utilisé pour autre chose.

— Andras Zoltan

Dans une certaine mesure, vous êtes libre de faire ce que vous voulez avec les codes, mais je conviendrais que vous pouvez utiliser 503, ou si vous le souhaitez 402, sans que personne ne puisse se plaindre que vous enfreignez les règles.

Edit: Un puriste pourrait dire que vous devriez commencer par 503, puis basculer une fois qu'il est possible d'effectuer des paiements.

Un excellent ajout à cela dans les commentaires:

Un 4xx indique une erreur du client qui peut être corrigée en effectuant une action donnée, alors qu'un 5xx indique un problème sur le serveur que le client ne peut pas résoudre. Donc, dans votre cas, un 4xx est plus approprié, car le (i) le serveur se comporte exactement comme il se doit, et (ii) le client peut "réparer" l'erreur en ralentissant ou en achetant plus de crédits. La résolution exacte peut être indiquée dans le corps de la réponse. - Mike Chamberlain Il y a 7 heures

— Marcin
source

503! 503! 503! Atteint la limite, le prochain appel est interdit.

— Clair

@YannisRizos: Ah, mais ce n'est pas interdit une fois le paiement effectué!

— Marcin

Le code d'erreur représente le résultat de la requête unique. Si le paiement a été effectué, lors d'une demande ultérieure, les choses se déroulent comme d'habitude ... Si vous documentez le comportement, tout va bien pour moi. Ou vous pouvez simplement renvoyer 200 avec un message d'erreur. Mais ce n'est pas joli. Bien que certains puissent dire que l'utilisation de codes d'erreur HTTP pour la logique métier n'est pas belle. Eh bien, personnellement, je choisirais 503, le service n’est pas disponible pour le moment - jusqu’à ce que bien sûr le 402 soit couramment pris en charge.

— Yannis

@YannisRizos (& Marcin) - Merci pour vos commentaires - J'ai pensé que 503 était le meilleur choix; Il est également important de comprendre que les implémentations de type RESTful peuvent souvent manquer de laine quand il s'agit d'utiliser des codes d'état HTTP. Mon point de vue personnel à ce sujet est d'utiliser ce que le protocole fournit à moins que cela ne corresponde pas (ce qui est en fait très rare). Dans ce cas, c'est le cas!

— Andras Zoltan

Un 4xx indique une erreur du client qui peut être corrigée en effectuant une action donnée, alors qu'un 5xx indique un problème sur le serveur que le client ne peut pas résoudre. Donc, dans votre cas, un 4xx est plus approprié, car le (i) le serveur se comporte exactement comme il se doit, et (ii) le client peut "réparer" l'erreur en ralentissant ou en achetant plus de crédits. La résolution exacte peut être indiquée dans le corps de la réponse.

— Mike Chamberlain