Código de estado HTTP recomendado para la respuesta de "límite de plan excedido"

Estoy diseñando una API REST para un proyecto donde los usuarios siempre están en uno de varios "planes": cada plan define algunos límites de recursos, como la cantidad máxima de usuarios que puede tener una cuenta o la cantidad máxima de datos que pueden cargar. Una vez que se alcanza uno de estos límites, los usuarios pueden actualizar sus planes (esencialmente pagar) para obtener más recursos.

Quiero devolver un código de estado especial que indique una situación en la que la acción no se puede realizar debido a los límites de recursos de la cuenta, y la actualización del plan lo resolverá, por ejemplo, si un usuario usa el 100% de su capacidad de almacenamiento e intenta cargar un archivo adicional , obtendrán esta respuesta.

Los candidatos son, en mi humilde opinión:

• 403 Forbidden - Sin embargo, me gustaría distinguir entre este caso y otros casos en los que el usuario simplemente no tiene el permiso para realizar esta acción.

• 401 Unauthorized - No es una buena idea, estamos usando esto para problemas relacionados con la autenticación.

• 402 Payment Required tiene sentido, pero me preocupa usar un código de estado no estándar pero reservado

• Algo aún menos estándar como 423 Lockedes poco probable que lo usemos para cualquier otra cosa en el futuro

Otra opción es ir con algo muy estándar, como 403indicar los detalles del error en el cuerpo de la respuesta.

Me pregunto qué enfoque crees que (a) funcionaría mejor a largo plazo y (b) se apegaría mejor a los principios RESTful.

Creo que 403 es la única respuesta razonable, aunque el método 405 no permitido o el conflicto 409 podrían ser aceptables, no creo que ninguno sea tan bueno como 403, que establece:

El servidor entendió la solicitud, pero se niega a cumplirla. La autorización no ayudará y la solicitud NO DEBE repetirse. Si el método de solicitud no era HEAD y el servidor desea hacer público por qué la solicitud no se ha cumplido, DEBERÍA describir el motivo del rechazo en la entidad

Si devuelve un error 403, incluirá información sobre por qué se denegó el recurso: el permiso no válido es solo el caso más común, los límites excedidos no son muy diferentes, no tiene permiso porque se excedió su límite.

Creo que 403 está mal, porque 403 es para situaciones en las que no está obteniendo acceso al recurso, y no hay forma alguna de obtener acceso. Para sus clientes, obviamente hay una forma de obtener acceso: pagar.

401 está realmente mal, porque no solo lo está utilizando para la autenticación, sino que para eso está allí.

Como está escribiendo una API, supongo que alguien más tendrá que escribir código que use la API, y esa persona necesita leer las especificaciones de su API. Puede ir con 429 "Demasiadas solicitudes". Por lo general, está destinado a limitar la tasa (donde un cliente puede hacer 100 solicitudes por día, por ejemplo), pero se aplica razonablemente a su situación. 402 (pago requerido) también sería aceptable, creo. Depende de qué herramientas esperes que la gente use para usar tu API. 429 tiene el riesgo de que una herramienta inteligente intente enviar menos solicitudes por minuto / hora / día y nunca tenga éxito.

Por cierto, de acuerdo con https://tools.ietf.org/html/rfc6585, el error 429 también debe contener un mensaje html que describa la naturaleza del problema, por lo que hay una buena posibilidad de que el usuario realmente sepa cuál es el problema, si proporciona esa información en tu respuesta.

WebDAV usa HTTP 507 Insufficient Storage para esto e incluye un código de error adicional para la cuota excedida en el cuerpo de la solicitud, para distinguirlo de otros tipos de limitaciones de almacenamiento.