Code d'état HTTP recommandé pour la réponse «Limite du plan dépassée»

Je conçois une API REST pour un projet où les utilisateurs sont toujours sur l'un des plusieurs "plans" - chaque plan définit des limites de ressources, telles que le nombre maximum d'utilisateurs qu'un compte peut avoir ou le nombre maximum de données qu'ils peuvent télécharger. Une fois que l'une de ces limites est atteinte, les utilisateurs peuvent mettre à niveau leurs plans (essentiellement payer) pour obtenir plus de ressources.

Je souhaite renvoyer un code d'état spécial indiquant une situation dans laquelle l'action ne peut pas être effectuée en raison des limites des ressources du compte, et la mise à niveau du plan résoudra ce problème - par exemple, si un utilisateur utilise 100% de sa capacité de stockage et essaie de télécharger un fichier supplémentaire , ils obtiendront cette réponse.

Les candidats sont, à mon humble avis:

• 403 Forbidden - cependant, je voudrais faire la distinction entre ce cas et d'autres cas où l'utilisateur n'a tout simplement pas l'autorisation d'effectuer cette action.

• 401 Unauthorized - ce n'est pas une bonne idée, nous l'utilisons pour des problèmes liés à l'authentification.

• 402 Payment Required - est assez logique, mais je crains d'utiliser un code d'état non standard mais réservé

• Quelque chose d'encore moins standard, 423 Lockedcar il est peu probable que nous l'utilisions pour autre chose à l'avenir

Une autre option consiste à opter pour quelque chose de très standard tel que 403mais d'indiquer les détails de l'erreur dans le corps de la réponse.

Je me demande quelle approche vous pensez (a) fonctionnerait le mieux à long terme et (b) respecterait mieux les principes RESTful.

Je pense que le 403 est la seule réponse raisonnable, bien que la méthode 405 non autorisée ou le conflit 409 puisse être acceptable, je ne pense pas que ce soit aussi bon que le 403 qui dit:

Le serveur a compris la demande, mais refuse de la satisfaire. L'autorisation n'aidera pas et la demande NE DEVRAIT PAS être répétée. Si la méthode de demande n'était pas HEAD et que le serveur souhaite rendre public pourquoi la demande n'a pas été satisfaite, il DEVRAIT décrire la raison du refus dans l'entité

Si vous renvoyez une erreur 403, cela inclura des informations sur la raison pour laquelle la ressource a été refusée - une autorisation non valide n'est que le cas le plus courant, les limites dépassées ne sont pas très différentes - vous n'avez pas l'autorisation parce que votre limite a été dépassée.

Je crois que 403 est faux, parce que 403 est pour des situations où vous n'avez pas accès à la ressource, et il n'y a aucun moyen d'y accéder. Pour vos clients, il existe évidemment un moyen d'y accéder: Payez.

401 est vraiment faux, car non seulement vous l'utilisez pour l'authentification, mais c'est pour cela qu'il est là.

Puisque vous écrivez une API, je suppose que quelqu'un d'autre devra écrire du code qui utilise l'API et que cette personne doit lire vos spécifications d'API. Vous pourriez aller avec 429 "Trop de demandes". Il est généralement destiné à limiter les tarifs (où un client peut faire 100 demandes par jour, par exemple), mais s'applique raisonnablement à votre situation. 402 (Paiement requis) serait également acceptable, je pense. Cela dépend des outils que vous attendez des gens qu'ils utilisent pour utiliser votre API. 429 présente le risque qu'un outil intelligent essaie d'envoyer moins de demandes par minute / heure / jour et ne réussisse jamais.

BTW selon https://tools.ietf.org/html/rfc6585, l'erreur 429 devrait également contenir un message html décrivant la nature du problème, donc il y a de fortes chances que l'utilisateur soit réellement informé du problème, si vous fournissez cette information dans votre réponse.

WebDAV utilise HTTP 507 Stockage insuffisant pour cela et inclut un code d'erreur supplémentaire pour le quota dépassé dans le corps de la demande, pour le distinguer des autres types de limitations de stockage.