HTTP 202 aceptado (HTTP / 1.1)
Estás buscando el HTTP 202 Acceptedestado. Ver RFC 2616 :
La solicitud ha sido aceptada 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 (Procesando) es una respuesta provisional utilizada para informar al cliente que el servidor ha aceptado la solicitud completa, pero aún no la 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 sobre el progreso. Envíe HTTP 102 y vacíe la respuesta byte por byte (o línea por línea).
Por ejemplo, para un proceso largo pero lineal, puede enviar cien puntos, enjuagando después de cada carácter. 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 eventualmente se mostrará al usuario, para que el usuario final pueda saber cómo va el proceso.
Problemas con el enrojecimiento progresivo
Tenga en cuenta que si bien esta técnica tiene sus méritos, 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 HTTP 202 Acceptedy dejar que el usuario se comunique contigo más tarde para determinar si el procesamiento finalizó (por ejemplo, llamando repetidamente a un URI dado, como el /process/resultque respondería con HTTP 404 no encontrado o HTTP 409 Conflict hasta el proceso finaliza y el resultado está listo), o notifique al usuario cuando se realiza el procesamiento si puede volver a llamar al cliente, por ejemplo, a través de un servicio de cola de mensajes ( ejemplo ) o WebSockets.
Ejemplo práctico
Imagine 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 hacer 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 Acceptedcontenido JSON, lo que significa "Sí, obtuve su video y estoy trabajando en ello; estará listo en algún momento 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
lo que lleva a un HTTP 200.
¿Qué sucede si el cliente consulta este URI antes de recibir la notificación? Bueno, el servidor responderá HTTP 404ya que, de hecho, el video aún no existe. Puede estar actualmente preparado. Puede que nunca se haya solicitado. Puede existir en algún momento en el pasado y eliminarse más tarde. Lo único que importa es que el video resultante no está disponible.
Ahora, ¿qué pasa si el cliente no solo se preocupa por el video final, sino también por 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 usar otro punto final:
GET /video/status/123
lo que daría 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/convertpone en cola una tarea. Debería llamarse solo una vez: llamarlo nuevamente pondría en cola una tarea adicional.GET /video/download/123se 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/123se refiere al procesamiento per se . No hace cola para nada. No le importa el video resultante. El recurso es el procesamiento en sí. Se puede llamar una o varias veces.