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é?

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...

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