http - code - status 304
¿Cómo elijo un código de estado HTTP en la API REST para "No listo todavía, inténtelo más tarde"? (8)
Estoy desarrollando una API RESTful en la que http://server/thingyapi/thingyblob/1234 devuelve el archivo (también conocido como "blob") asociado con la función # 1234 para descargar. Pero puede ser que la solicitud se realice en un momento en que el archivo no existe en el servidor, pero definitivamente estará disponible en otro momento. Hay un proceso por lotes en el servidor que genera todos los blobs para todas las cosillas. Thingy 1234 ya existe y sus datos, además del blob, ya están disponibles. El servidor aún no ha generado la burbuja de thingy 1234.
No quiero devolver 404; eso es para cosas que no existen. Esto es algo que existe, pero su blob no se ha generado aún. Un poco como un video de YouTube que es "procesamiento". No creo que los códigos de redirección sean adecuados tampoco; no hay una "otra" URL para probar.
¿Cuál es el código de estado HTTP correcto para devolver en tal caso?
No quiero devolver 404; eso es para cosas que no existen.
La URL no corresponde a una solicitud de una cosa.
http://server/thingyapi/thingyblob/1234
El cliente está solicitando un thingyblob, que no existe. Si existiera, se lo darías.
404.
409 Conflicto
Indica que la solicitud no se pudo procesar debido a un conflicto en la solicitud, como un conflicto de edición en el caso de múltiples actualizaciones. [Fuente Wikipedia.]
Esto podría ser apropiado.
Si no puede cumplir con la solicitud devolviendo los datos, entonces no es un éxito. Creo que 202 sugiere que el servidor ha puesto en cola la solicitud y cumplirá la solicitud más tarde. Pero en su caso, la solicitud ahora es de datos y ha fallado. Si vuelve a intentar más tarde, es una solicitud diferente.
Creo que tienes un conflicto ... quieres los datos ... pero están siendo editados / actualizados. Este también sería el caso si Thingy1234 ya existía y se había descargado con éxito antes, pero ahora estaba en proceso de edición y no estaba disponible mientras se llevaba a cabo la edición.
501 - No implementado
Exactamente como suena Una característica que aún no está implementada, pero implica disponibilidad futura.
Aquí hay un enlace a un resumen de errores 5xx .
Como su recurso no está listo, probablemente sepa cuándo (aproximadamente) estará disponible y cuándo el cliente puede volver a intentar su solicitud. Esto significa que es posible que desee utilizar el encabezado Retry-After . Este encabezado es válido con 503 (Servicio no disponible), lo que significa que todo el sitio está fuera de servicio por mantenimiento, y respuestas 3xx (Redirección).
En mi opinión, 302 (Encontrado) con cabecera Reintentar-Después sería la mejor opción, pero no estoy seguro de si el campo Ubicación del encabezado de respuesta puede ser igual a la URL de solicitud. Es una redirección circular, de todos modos.
Creo que 423 - Locked se puede usar para este propósito:
El código de estado 423 (Bloqueado) significa que el recurso fuente o de destino de un método está bloqueado. Esta respuesta DEBERÍA contener un código de precondición o de condición posterior apropiado, como ''lock-token-submitted'' o ''no-conflicting-lock''.
El "problema", tal como está, está en el lado del servidor: el cliente ha realizado una solicitud bien formada, pero el servidor no puede satisfacerla. Entonces me inclino a un "Error de Servidor", código de estado 5xx. Quoth el estándar :
Los códigos de estado de respuesta que comienzan con el dígito "5" indican casos en los que el servidor sabe que se ha equivocado o no puede realizar la solicitud ... el servidor DEBERÍA incluir una entidad [indicando] si se trata de una condición temporal o permanente.
Nota
- "erró o es incapaz de realizar la solicitud": a pesar de su título de "Error de servidor", no son solo por errores del servidor.
- " temporal o permanente": estos códigos son adecuados para recursos temporalmente no disponibles, como el suyo.
De los códigos disponibles, diría que 503, "Servicio no disponible" fue la mejor opción:
El servidor actualmente no puede manejar la solicitud debido a una sobrecarga temporal o mantenimiento del servidor. La implicación es que esta es una condición temporal que se aliviará después de un poco de retraso. Si se conoce, la duración de la demora PUEDE indicarse en un encabezado Retry-After. Si no se da Reintentar-Después, el cliente DEBERÍA manejar la respuesta como lo haría con una respuesta de 500.
Nota:
- "una condición temporal que se aliviará después de un retraso": cierto para su caso.
- "sobrecarga temporal": no es pedantemente cierto para su caso. Pero, podría argumentarse, si su servidor fuera mucho más rápido, el procesamiento por lotes ya se habría realizado cuando el cliente realizó la solicitud, por lo que es una especie de "sobrecarga": el cliente está pidiendo recursos más rápido de lo que el servidor puede hacer ellos disponibles.
- "el cliente DEBERÍA manejar la respuesta como lo haría con una respuesta 500": que es "Error interno del servidor", el tipo de respuesta cuando el servidor falla debido a un error. El estándar parece implicar que un cliente con buena conducta no debe volver a intentarlo en este caso. Reintentar es adecuado para su servicio, por lo que su respuesta debe incluir un valor de
Retry-After. Puede proporcionar como valor el tiempo estimado de finalización de la próxima ejecución del proceso por lotes o el intervalo de ejecución del proceso por lotes.
La definición de su propio código de estado 5xx (591, por ejemplo), aunque está permitted , tendría una semántica incorrecta:
Los códigos de estado HTTP son extensibles ... las aplicaciones DEBEN comprender la clase de cualquier código de estado, como lo indica el primer dígito, y tratan cualquier respuesta no reconocida como equivalente al código de estado x00 de esa clase
Los clientes tratarían su propio código de estado como 500, "Error interno del servidor", que (como mencioné anteriormente) no sería correcto.
Otra opción: 503 - Service Unavailable .
Sugiero 202 - Accepted . De la documentation :
La solicitud se ha aceptado para su procesamiento, pero el procesamiento no se ha completado. [...] Su propósito es permitir que un servidor acepte una solicitud para algún otro proceso (tal vez un proceso orientado a lotes que solo se ejecuta una vez al día)