HTTP 202 aceptado (HTTP / 1.1)
Está buscando el estado de HTTP 202 Accepted . Consulte RFC 2616 :
La solicitud se ha aceptado para su procesamiento, pero el procesamiento no se ha completado.
Procesamiento HTTP 102 (WebDAV)
RFC 2518 sugiere usar HTTP 102 Processing :
El código de estado 102 (Procesamiento) es una respuesta provisional utilizada para
informar al cliente que el servidor ha aceptado la solicitud completa,
pero aún no lo ha completado.
pero tiene una advertencia:
El servidor DEBE enviar una respuesta final después de que se haya completado la solicitud.
No estoy seguro de cómo interpretar la última oración. ¿Debería el servidor evitar enviar algo durante el procesamiento y responder solo después de la finalización? ¿O solo obliga a finalizar la respuesta solo cuando finaliza el procesamiento? Esto podría ser útil si desea informar el progreso. Envíe HTTP 102 y vacíe el byte por byte (o línea por línea).
Por ejemplo, para un proceso largo pero lineal, puedes enviar cien puntos, limpiando después de cada personaje. Si el lado del cliente (como una aplicación de JavaScript) sabe que debe esperar exactamente 100 caracteres, puede coincidir con una barra de progreso para mostrar al usuario.
Otro ejemplo se refiere a un proceso que consta de varios pasos no lineales. Después de cada paso, puede vaciar un mensaje de registro que finalmente se mostraría al usuario, para que el usuario final pueda saber cómo va el proceso.
Problemas con el lavado progresivo
Tenga en cuenta que si bien esta técnica tiene sus ventajas, no la recomendaría . Una de las razones es que obliga a que la conexión permanezca abierta, lo que podría perjudicar en términos de disponibilidad del servicio y no se escala bien.
Un mejor enfoque es responder con HTTP 202 Accepted y dejar que el usuario se comunique con usted más tarde para determinar si el procesamiento terminó (por ejemplo, llamando repetidamente a un URI determinado, como /process/result , que respondería con HTTP 404 No encontrado o HTTP 409 Conflict hasta que el proceso finalice y el resultado esté listo), o notifique al usuario cuando se realice el procesamiento si puede devolver la llamada al cliente, por ejemplo, a través de un servicio de cola de mensajes ( example ) o WebSockets.
Ejemplo práctico
Imagina un servicio web que convierte videos. El punto de entrada es:
POST /video/convert
que toma un archivo de video de la solicitud HTTP y hace algo de magia con él. Imaginemos que la magia requiere mucha CPU, por lo que no se puede realizar en tiempo real durante la transferencia de la solicitud. Esto significa que una vez que se transfiere el archivo, el servidor responderá con un HTTP 202 Accepted con algo de contenido JSON, lo que significa "Sí, recibí tu video y estoy trabajando en ello; estará listo en algún lugar en el futuro y estará disponible a través de la ID 123 ".
El cliente tiene la posibilidad de suscribirse a una cola de mensajes para recibir una notificación cuando finalice el procesamiento. Una vez finalizado, el cliente puede descargar el video procesado yendo a:
GET /video/download/123
que lleva a un HTTP 200 .
¿Qué sucede si el cliente consulta este URI antes de recibir la notificación? Bueno, el servidor responderá con HTTP 404 ya que, de hecho, el video todavía no existe. Puede estar actualmente preparado. Puede que nunca haya sido solicitado. Puede existir algún tiempo en el pasado y ser eliminado más tarde. Lo único que importa es que el video resultante no está disponible.
Ahora, ¿qué pasa si al cliente no solo le interesa el video final, sino también el progreso (que sería aún más importante si no hay un servicio de cola de mensajes o algún mecanismo similar)?
En este caso, puede utilizar otro punto final:
GET /video/status/123
lo que daría como resultado una respuesta similar a esta:
HTTP 200
{
"id": 123,
"status": "queued",
"priority": 2,
"progress-percent": 0,
"submitted-utc-time": "2016-04-19T13:59:22"
}
Hacer la solicitud una y otra vez mostrará el progreso hasta que sea:
HTTP 200
{
"id": 123,
"status": "done",
"progress-percent": 100,
"submitted-utc-time": "2016-04-19T13:59:22"
}
Es crucial hacer una diferencia entre esos tres tipos de solicitudes:
-
POST /video/convert pone en cola una tarea. Se debe llamar solo una vez: volver a llamar sería una tarea adicional.
-
GET /video/download/123 se refiere al resultado de la operación: el recurso es el video. El procesamiento, que es lo que sucedió bajo el capó para preparar el resultado real antes de la solicitud e independientemente de la solicitud, es irrelevante aquí. Se puede llamar una o varias veces.
-
GET /video/status/123 se refiere al procesamiento per se . No hace cola nada. No le importa el video resultante. El recurso es el procesamiento en sí mismo. Se puede llamar una o varias veces.