Código de estado HTTP REST sugerido para 'límite de solicitud alcanzado'

Estoy reuniendo una especificación para un servicio REST, parte del cual incorporará la capacidad de estrangular a los usuarios en todo el servicio y en grupos de recursos individuales o en grupos. Igualmente, los tiempos de espera para estos serían configurables por recurso / grupo / servicio.

Solo estoy mirando a través de la especificación HTTP 1.1 y tratando de decidir cómo voy a comunicarle a un cliente que una solicitud no se cumplirá porque han alcanzado su límite.

Inicialmente pensé que el código del cliente 403 - Forbiddenera el indicado, pero esto, según la especificación:

La autorización no ayudará y la solicitud NO DEBE repetirse

me molestó.

En realidad, parece que 503 - Service Unavailablees mejor usarlo, ya que permite la comunicación de un tiempo de reintento mediante el uso del Retry-Afterencabezado.

Es posible que en el futuro intente admitir 'comprar' más solicitudes a través del comercio electrónico (¡en cuyo caso sería bueno si se 402 - Payment Requiredhubiera finalizado el código del cliente !), Pero creo que esto también podría exprimirse en una respuesta 503.

¿Cuál crees que debería usar? ¿O hay otro que no he considerado?

web-services rest http

— Andras Zoltan
fuente

Respuestas:

429 Demasiadas solicitudes

El usuario ha enviado demasiadas solicitudes en un período de tiempo determinado. Diseñado para su uso con esquemas de limitación de velocidad. Este código ha sido aceptado en RFC 6585 Códigos de estado HTTP adicionales .

   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
fuente

Suena increíble, lo tendré en cuenta. ¿Viene con gatos gratis? ¿O son una extensión del protocolo?

— Andras Zoltan

HTTP Status cats: para todas sus necesidades de estado: flickr.com/photos/girliemac/sets/72157628409467125

— Sean McMillan el

eso acaba de dar la vuelta a la oficina con muchas risas y aplausos - ¡genio!

— Andras Zoltan

Fui con un 429 al final, está en el borrador, pero dudo seriamente que termine siendo utilizado para cualquier otra cosa.

— Andras Zoltan

Hasta cierto punto, eres libre de hacer lo que quieras con los códigos, pero estaría de acuerdo en que puedes usar 503, o si lo deseas 402, sin que nadie pueda quejarse de que estás rompiendo cosas.

Editar: un purista podría decir que debe comenzar con 503, luego cambiar una vez que sea posible realizar pagos.

Una excelente adición a esto en los comentarios:

Un 4xx indica un error por parte del cliente que puede ser reparado por ellos realizando una determinada acción, mientras que un 5xx indica un problema en el servidor que el cliente no puede ayudar a resolver. Entonces, en su caso, un 4xx es más apropiado, porque (i) el servidor se comporta exactamente como debería, y (ii) el cliente puede "arreglar" el error ya sea disminuyendo la velocidad o comprando más créditos. La resolución exacta se puede indicar en el cuerpo de la respuesta 429. - Mike Chamberlain hace 7 horas

— Marcin
fuente

503! 503! 503! Alcanzado el límite, la próxima llamada está prohibida. Claro y simple ...

— Yannis

@YannisRizos: Ah, ¡pero no está prohibido una vez que se haya realizado el pago!

— Marcin

El código de error representa el resultado de la solicitud única. Si el pago se realizó, en una solicitud posterior, todo sigue como de costumbre ... Si documenta el comportamiento, estoy bien. O simplemente puede devolver 200, con un mensaje de error. Pero eso no es bonito. Aunque algunos podrían decir que usar códigos de error HTTP para la lógica empresarial no es bonito. Ah, bueno, personalmente iría con 503, el servicio no está disponible en este momento, hasta que, por supuesto, 402 es comúnmente compatible.

— Yannis

@YannisRizos (& Marcin) - gracias por sus comentarios - pensé que 503 era el mejor para ir; al mismo tiempo que comprende que las implementaciones de naturaleza RESTful a menudo pueden ser desagradables cuando se trata de usar códigos de estado HTTP. Mi punto de vista personal sobre esto es usar lo que proporciona el protocolo a menos que no se ajuste (lo que en realidad es muy raro). En este caso, definitivamente lo hace.

— Andras Zoltan

Un 4xx indica un error por parte del cliente que puede ser reparado por ellos realizando una determinada acción, mientras que un 5xx indica un problema en el servidor que el cliente no puede ayudar a resolver. Entonces, en su caso, un 4xx es más apropiado, porque (i) el servidor se comporta exactamente como debería, y (ii) el cliente puede "arreglar" el error ya sea disminuyendo la velocidad o comprando más créditos. La resolución exacta se puede indicar en el cuerpo de la respuesta 429.

— Mike Chamberlain