web-dev-qa-db-fra.com

Suggéré HTTP REST code d'état pour «limite de demande atteinte»

Je prépare une spécification pour un service REST, dont une partie intégrera la capacité de limiter les utilisateurs à l'échelle du service et sur des groupes de ressources ou sur des ressources individuelles. De même, les délais d'expiration car ceux-ci seraient configurables par ressource/groupe/service.

Je regarde simplement la spécification HTTP 1.1 et j'essaie de décider comment je vais communiquer à un client qu'une demande ne sera pas satisfaite parce qu'il a atteint sa limite.

Au départ, je pensais que le code client 403 - Forbidden était celui, mais cela, d'après les spécifications:

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

m'a ennuyé.

Il semble que 503 - Service Unavailable est préférable à utiliser - car il permet la communication d'un temps de nouvelle tentative grâce à l'utilisation de Retry-After entête.

Il est possible qu'à l'avenir je cherche à prendre en charge l'achat de plus de demandes via le commerce électronique (auquel cas ce serait bien si le code client 402 - Payment Required avait été finalisé!) - mais je pense que cela pourrait également être inclus dans une réponse 503.

Que pensez-vous que je devrais utiliser? Ou y en a-t-il un autre que je n'ai pas envisagé?

web-servicesresthttp
45
Andras Zoltan

429 Trop de demandes

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

http://i.stack.imgur.com/Y84Lj.jpg

   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...
79
Sean McMillan

Dans une certaine mesure, vous êtes libre de faire ce que vous voulez avec les codes, mais je conviens que vous pouvez utiliser 503, ou si vous voulez 402, sans que personne ne puisse se plaindre que vous cassez des choses.

Edit: Un puriste pourrait dire que vous devriez commencer par 503, puis changer 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 par lui en effectuant une certaine action, tandis 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 (i) le serveur se comporte exactement comme il se doit, et (ii) le client peut "corriger" 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 429. - Mike Chamberlain Il y a 7 heures

7
Marcin