Elegir el código de respuesta HTTP correcto para datos posteriores a la publicación incorrecta

Question

Sospecho que esta es una pregunta muy trivial. Estoy escribiendo un script PHP para responder a una consulta AJAX. La consulta debe incluir algunos datos XML, que el script PHP procesa y luego devuelve una respuesta. Hay dos casos de error que quiero considerar:

1. No hay datos post en la solicitud; o
2. Datos malos en el XML (no es válido o bien formado XML, o falla algunas verificaciones de esquema)

En tales casos, creo que debería devolver un código de respuesta 4XX. ¿Hay algo más apropiado que 400?

Más detalles

Para ilustrar aún más el problema: la aplicación JavaScript del cliente es un editor de diagrama con fines educativos. Se requiere que el usuario cree un diagrama que modela correctamente una situación dada. El estudiante puede enviar el diagrama, por el cual se publica una serialización XML del diagrama a través de una llamada AJAX al servidor. Un script PHP analiza el Diagrama XML y construye un informe XML que se envía como respuesta AJAX al cliente. Las dos situaciones que describí originalmente (ningún XML Post Data o XML inválido no deberían ocurrir cuando el cliente lo solicite, pero creo que es prudente capturar y tratar correctamente estas situaciones. De ahí mi creencia de que un código de respuesta 4XX es apropiado. La estructura del informe XML no atiende a estas situaciones, y un informe vacío equivaldría a un diagrama perfecto, que claramente no es apropiado,

Answer 1

Basado en los significados de los códigos en el Guía TCP/IP Parece que 400 es tu mejor opción. Parece que nada de eso cumplir con tu ejemplo.

Answer 2

Creo que los dos casos de error que mencionó en realidad se servirían con diferentes códigos de estado HTTP. Desde el Definiciones de código de estado de W3C:

400 Petición Incorrecta - La solicitud no pudo ser entendida por el servidor debido a la sintaxis malformada. El cliente no debe repetir la solicitud sin modificaciones.

409 conflicto - La solicitud no se pudo completar debido a un conflicto con el estado actual del recurso ... Por ejemplo, si se usaban versiones y la entidad que se colocaba incluía cambios en un recurso que conflicto con los que se realizan por un anterior (tercero (tercero -Party) Solicitud, el servidor podría usar la respuesta 409 para indicar que no puede completar la solicitud ...

Entonces, el 400 es para los casos en que el cuerpo de solicitud ni siquiera se puede analizar debido a problemas de sintaxis. El 409, en contraste, parece ser para los casos en que el cuerpo de la solicitud se analiza y el servidor comprende la solicitud bien, pero se niega a cumplirlo debido a las reglas comerciales.

En el caso de la validación de esquema de falla o la sintaxis XML mala, estoy de acuerdo con los otros carteles, 400 es apropiado. Pero en el caso de no hay datos post, que usted dice que es un diagrama válido pero no aceptable por otras razones, 409 me parece más apropiado.