Código de estado HTTP para una solicitud satisfactoria parcial

Tengo una aplicación que envía mensajes a los usuarios. En una solicitud de publicación se transfiere una cadena XML que consta de todos los usuarios que deberían recibir ese mensaje en particular. Si alguno de los usuarios de la lista no existe, le devuelvo la lista de usuarios perdidos al cliente para una evaluación adicional.

Ahora me pregunto cuál sería el código de estado adecuado para la aplicación que dice que la solicitud fue aceptada pero que hubo cosas que no se pudieron hacer.

El problema se evitaría si no se permitiera incluir a los usuarios que faltan en la lista. Entonces, el intento de envío solo obtendría un error 4xx. Pero no tiene sentido formar la API de esta manera. Por otro lado, podría considerar que la condición de error es puramente específica de la aplicación. Pero enviar un 200 simplemente no se siente bien. Y sería bueno darle al cliente una pista sobre cuándo mirar en profundidad la respuesta de error. por ejemplo, para evitar enviar mensajes a esos usuarios una y otra vez

Me he ocupado de un problema muy similar. En este caso, devolví un

207 multiestado

Ahora, esto no es HTTP estricto, es parte de la extensión WebDAV, así que si no tienes control sobre el cliente también, entonces esto no es bueno para ti. Si lo hace, podría hacer algo como esto:

   <?xml version="1.0" encoding="utf-8" ?>
   <D:multistatus xmlns:D='DAV:'>
     <D:response>
       <D:user>user-123</D:user>
       <D:status>success</D:status>
     </D:response>
     <D:response>
       <D:user>user-789</D:user>
       <D:status>failure</D:status>
     </D:response>
   </D:multistatus>

Pero, de nuevo, esta es una extensión HTTP y también debe tener el control del cliente.

Tuve el mismo problema y terminé usando dos soluciones diferentes:

• Código de retorno HTTP 202: Accepted, que indica que la solicitud fue correcta, pero no hay garantía de que todo haya ido como debería.
• Devuelve un valor normal 200en la respuesta, pero incluye una lista de lo que no resultó en el cuerpo de la respuesta.

El segundo generalmente funciona mejor, pero el primero es excelente si eres vago o usas una cola para procesar.

¿Qué hay de usar 206 Partial Content? Sé que 206 se trata más de rangos, pero ¿y si pudiera indicar una solicitud parcialmente exitosa?

El Protocolo de transferencia de hipertexto se ocupa del lado de la transmisión de las cosas. No tiene códigos de error para lidiar con errores de nivel de aplicación.

Devolver 200 es lo correcto aquí. En lo que respecta a HTTP, la solicitud se recibió correctamente, se manejó correctamente y está enviando la respuesta. Entonces, en el nivel HTTP, todo está bien. Cualquier error o advertencia relacionado con la aplicación que se ejecuta sobre http debe estar dentro de la respuesta. Si lo hace, también evitará algunos problemas desagradables que puede encontrar con los servidores proxy que pueden no manejar ciertas respuestas de la manera esperada.