¿Está mal devolver 202 "Accepted" en respuesta a HTTP GET?
Tengo un conjunto de recursos cuyas representaciones se crean perezosamente. El cálculo para construir estas representaciones puede tomar desde unos pocos milisegundos hasta unas pocas horas, dependiendo de la carga del servidor, el recurso específico y la fase de la luna.
La primera solicitud GET recibida para el recurso inicia el cómputo en el servidor. Si el cálculo se completa en unos pocos segundos, se devuelve la representación calculada. De lo contrario, un código de estado "Aceptado" 202 es devuelto, y el cliente debe sondear el recurso hasta que la representación final esté disponible.
La razón de este comportamiento es la siguiente: Si un resultado está disponible en unos pocos segundos, necesita ser recuperado lo antes posible; de lo contrario, cuando esté disponible no es importante.
Debido a la memoria limitada y el gran volumen de solicitudes, ni NIO ni long polling son una opción (es decir, No puedo mantener suficientes conexiones abiertas, ni siquiera puedo encajar todas de las solicitudes en la memoria; una vez que han pasado "unos segundos", persisto el exceso de solicitudes). Del mismo modo, las limitaciones del cliente son tales que no pueden manejar una devolución de llamada de finalización, en su lugar. Finalmente, tenga en cuenta que no estoy interesado en crear un recurso de "fábrica" en el que uno publique, ya que los viajes de ida y vuelta adicionales significan que fallamos la restricción en tiempo real por partes más de lo deseado (además, es una complejidad adicional; también, este es un recurso que se beneficiaría del almacenamiento en caché).
Me imagino que hay algunos controversia sobre devolver un código de estado 202" Aceptado " en respuesta a una solicitud GET, ya que nunca lo he visto en la práctica, y su uso más intuitivo es en respuesta a métodos inseguros, pero nunca he encontrado nada que lo desaliente específicamente. Además, ¿no estoy preservando tanto la seguridad como la idempotencia?
Entonces, ¿qué piensan las personas acerca de este enfoque?
EDIT: Debo mencionar que esto es para una llamada API web de negocios not no para navegadores.
3 answers
Si es para una API bien definida y documentada, 202 suena exactamente correcto para lo que está sucediendo.
Si es para el Internet público, estaría demasiado preocupado por la compatibilidad del cliente. He visto tantos if (status == 200) codificados.... En ese caso, devolvería un 200.
Además, el RFC no indica que usar 202 para una solicitud GET sea incorrecto, mientras que hace distinciones claras en otras descripciones de código (por ejemplo, 200).
La solicitud tiene ha sido aceptado para su procesamiento, pero el procesamiento no se ha completado.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-11-04 18:51:05
Hicimos esto para una aplicación reciente, un cliente (aplicación personalizada, no un navegador) publicó una consulta y el servidor devolvería 202 con un URI al "trabajo" que se estaba publicando - el cliente usaría ese URI para sondear el resultado - esto parece encajar muy bien con lo que se estaba haciendo.
Lo más importante aquí es de todos modos documentar cómo funciona su servicio/API, y lo que significa una respuesta de 202.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-11-04 18:31:01
Por lo que puedo recordar - GET se supone que devuelve un recurso sin modificar el servidor. Tal vez se registre la actividad o lo que sea, pero la solicitud debe volver a ejecutarse con el mismo resultado.
POST por otro lado es una solicitud para cambiar el estado de algo en el servidor. Insertar un registro, borrar un registro, ejecutar un trabajo, algo así. 202 sería apropiado para un POST que regresó pero no está terminado, pero en realidad no es una solicitud GET.
Todo Es muy puritano y no se practica bien en la naturaleza, por lo que probablemente esté seguro al regresar 202. GET debería devolver 200. POST puede devolver 200 si está terminado o 202 si no está hecho.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-11-04 18:41:05