Código de estado HTTP para "éxito con errores"?

He hurgado un poco, pero no veo un código de estado HTTP para cuando una solicitud tiene éxito, pero hay un error después del "punto de no retorno".Código de estado HTTP para "éxito con errores"?

por ejemplo, supongamos que procesa una solicitud, está comprometida con la base de datos, pero al devolver el resultado se ejecuta la memoria, o encuentra un NPE, o lo que sea. Es ha sido una respuesta 200, pero ahora, internamente, no puede devolver la respuesta correcta y bien formada.

202 Accepted parece que no encaja porque ya procesamos la solicitud.

¿Qué código de estado significa "éxito, pero errores"? ¿Existe uno?

Fuente

2010-06-18 Richard Levasseur

En ese caso, debe asegurarse de que ya no ha enviado datos al cliente, porque ya ha pasado el punto de no retorno: antes de los primeros bytes de datos, los encabezados (incluido el código de estado) son enviado al navegador. –

Heh - concedido :). Supongo que estoy hablando del punto de no retorno antes de ese punto de no retorno. La mayoría de las veces, sin embargo, el código del lado del servidor construye la respuesta completa en la memoria antes de enviarlo, ya que por lo general son lo suficientemente pequeños como para hacerlo. –

Si el servidor es consciente de que ha encontrado un problema, normalmente debería devolver un error 5xx. El más genérico es la 500 Server Error, que la RFC 2616 define como sigue:

500 error interno del servidor

El servidor encontró una condición inesperada que le impidió de cumplir la petición.

A continuación, es responsabilidad del cliente volver a intentar la solicitud. Si la solicitud anterior fue parcialmente comprometida, es responsabilidad del servidor (o de la base de datos) devolverla o manejar la transacción duplicada de manera apropiada.

Fuente

2010-06-18 03:14:36

No estoy muy satisfecho con esta respuesta. ¿Qué significa "cumplir", exactamente? Hemos modificado el recurso de la forma que el cliente lo solicite. Si vuelven a cargar la página, verán los cambios. En lo que respecta al usuario, fue exitoso. Para mí, realmente parece que hemos cumplido la _request_, pero no hemos cumplido la _response_. –

@Richard: Siempre entendí "cumplir" para incluir la respuesta también (pero podría estar equivocado en esto). Sin embargo, este código de estado es muy genérico y debe usarse siempre que el servidor encuentre un problema que no pueda ser descrito por otro error 5xx más específico. Creo que [@Jim] (http://stackoverflow.com/users/45935/jim-ferrans) describió lo que tenía la intención de decir mejor, [en la otra respuesta] (http://stackoverflow.com/questions/3066972/ http-status-code-for-success-with-errors/3067090 # 3067090). –

Estoy de acuerdo con @Daniel en que la respuesta correcta es un HTTP 500 (error de servidor). La aplicación web debe escribirse para deshacer la transacción cuando hay un error, no dejar las cosas a medio terminar.

Una cosa que puede aprovechar en su aplicación web es "idempotencia". Esta es la propiedad de una función (u operación) que puede repetirla tantas veces como quiera con el mismo resultado. Por ejemplo, si una lectura falla, el cliente simplemente puede volver a intentarlo hasta que tenga éxito. Si una eliminación parece fallar, el cliente puede volver a intentarlo y el servidor tratará la solicitud como válida independientemente de si el recurso que se está eliminando ya ha desaparecido. Y si parece que una actualización falla, el cliente puede volver a intentarlo hasta que obtenga un retorno exitoso del servidor. El enfoque de REST para la arquitectura de servicios web hace un uso intensivo de la idempotencia para hacer que las operaciones sean robustas ante el error.

Fuente

2010-06-18 03:45:02

Para aclarar, la transacción ya está comprometida (por ejemplo, considere el caso cuando se produce OutOfMemoryError durante la codificación de la respuesta). Para implementar idempotencia, necesitaría implementar control de revisión, ¿no? Hacer que el servidor realice un seguimiento de los cambios enviados y que los clientes suministren y cambien la ID. También está el caso del manejo de errores no temporales (digamos que hay un error que resulta en un NPE en lugar de un error de falta de memoria) - el cliente puede volver a intentar todo lo que quiera, pero nunca tendrá éxito (a pesar de haber tenido éxito la primera vez, y los tiempos subsiguientes son redundantes). –

@Richard: "todo depende". Si se trata de una aplicación de administración de contenido y no te importa si dos actualizaciones "simultáneas" parecen estar fuera de estricto orden ocasionalmente, no tienes que hacer versiones. Pero el control de versiones o el sellado de tiempo puede ser apropiado si tiene restricciones más estrictas. Otro enfoque es formar la mayor parte de su respuesta dentro de los límites de la transacción como sea posible, por lo que un OOME haría abortar la transacción. Y tal vez las colas de mensajes persistentes que contienen solicitudes de transacciones y resultados podrían ser lo que desee (consulte Apache's ActiveMQ). +1 para las preguntas de sondeo –

HTTP no tiene dicho código de estado, pero hay una mejor práctica que le permite manejar tales situaciones: redirigir al usuario después de una operación POST.

Aquí hay un desglose -

petición UN POST intenta modificar datos en el servidor
Si el servidor falla, se envía un error 500 para indicar el fracaso
Si el servidor tiene éxito, se envía una respuesta de redirección 302
el navegador envía una petición GET nueva al servidor
Si esto falla, se obtiene un error 500, de lo contrario se obtiene un 200

Por lo tanto, su caso de uso de "Datos guardados pero no puede recuperarlo inmediatamente" se traduce en un redireccionamiento 302 para el POST inicial, seguido de un 500 para el GET subsiguiente.

Este enfoque tiene otras ventajas: te deshaces del molesto '¿Estás seguro de que deseas volver a enviar los datos?' mensaje. También mantiene utilizables los botones de atrás/adelante/actualizar.

Fuente

2010-06-18 05:40:02

Código de estado HTTP para "éxito con errores"?

Respuesta

Cuestiones relacionadas