xml - para - manual de programacion android pdf

Uso adecuado de los códigos de estado HTTP en un servidor de "validación"

Question

Entre los datos que mi aplicación envía a un servidor SOA de terceros hay XML complejos. El propietario del servidor proporciona los esquemas XML ( .xsd ) y, dado que el servidor rechaza los XML no válidos con un mensaje sin sentido, necesito validarlos localmente antes de enviarlos.

Podría usar un validador de esquema XML autónomo, pero son lentos, principalmente debido al tiempo requerido para analizar los archivos de esquema. Así que escribí mi propio validador de esquema (en Java, si eso importa) en la forma de un servidor HTTP que almacena en caché los esquemas ya analizados.

El problema es que muchas cosas pueden salir mal durante el proceso de validación. Aparte de las excepciones inesperadas y la validación exitosa:

• el servidor puede no encontrar el archivo de esquema especificado
• el archivo especificado puede no ser un archivo de esquema válido
• el XML no es válido contra el archivo de esquema

Como es un servidor HTTP, me gustaría proporcionar al cliente códigos de estado significativos. ¿Debería el servidor responder con un error 400 ( solicitud incorrecta ) para todos los casos anteriores? ¿O no tienen nada que ver con HTTP y deberían responder 200 con un mensaje en el cuerpo? ¿Alguna otra sugerencia?

Actualización : la aplicación principal está escrita en Ruby , que no tiene una buena biblioteca de validación de esquemas xml, por lo que un servidor de validación separado no está sobre-ingeniería.

Answer 1

Desde w3c: 400 = La solicitud no pudo ser entendida por el servidor debido a una sintaxis mal formada.

No lo publicaría a menos que fuera realmente el caso de que el servidor no pudiera entender la solicitud. Si solo está obteniendo xml no válido, brinde 200 y explique por qué las cosas no funcionan.

Saludos Fake

Answer 2

Me gustaría ir con 400 Bad request y un mensaje más específico en el cuerpo (posiblemente con un código de error secundario en un encabezado, como X-Parse-Error: 10451 para facilitar el procesamiento)

Answer 3

Parece una buena idea, pero los códigos de estado HTTP realmente no proporcionan un caso de "operación fallida". Devolvería HTTP 200 con un resultado X-Validation-Result: true/false , usando el cuerpo para cualquier texto o "razón" según sea necesario. Guarde el HTTP 4xx para errores de nivel HTTP, no errores a nivel de aplicación.

Sin embargo, es una pena y un doble estándar. Muchas aplicaciones usan autenticación HTTP y pueden devolver HTTP 401 No autorizado o 403 Prohibido desde el nivel de la aplicación. Sería conveniente y sensato tener algún tipo de solicitud HTTP 4xx rechazada que pueda usar.

Answer 4

Es un pensamiento perfectamente válido para asignar situaciones de error en el proceso de validación a códigos de estado HTTP significativos.

Supongo que envía el archivo XML a su servidor de validación como un contenido POST utilizando el URI para determinar un esquema específico para la validación.

Así que aquí hay algunas sugerencias para mapeos de error:

• 200: el contenido XML es válido
• 400: el contenido XML no estaba bien formado, el encabezado era inconsistente, la solicitud no coincidía con la sintaxis RFC 2616
• 401: el esquema no se encontró en la memoria caché y el servidor necesita credenciales para usar en la autenticación contra el servidor externo SOA para obtener el archivo de esquema
• 404: archivo de esquema no encontrado
• 409: el contenido XML no era válido para el esquema especificado
• 412: el archivo especificado no era un esquema válido de XMl
• 500: cualquier excepción inesperada en su servidor de validación (NullPointerExceptions et al.)
• 502: el esquema no se encontró en la memoria caché y el intento de solicitarlo desde el servidor SOA de terceros falló.
• 503: el servidor de validación está reiniciando
• 504: vea 502 con reason = timeout

Answer 5

Amazon podría usarse como modelo de cómo mapear códigos de estado http a condiciones de nivel de aplicación real: http://docs.amazonwebservices.com/AWSImportExport/latest/API/index.html?Errors.html (consulte el encabezado de códigos de estado de Amazon S3). )

Answer 6

El código de estado 422 ("Entidad no procesable") suena lo suficientemente cerca:

"El código de estado 422 (Entidad no procesable) significa que el servidor entiende el tipo de contenido de la entidad de solicitud (por lo tanto, un código de estado 415 (Tipo de medio no admitido) es inapropiado) y la sintaxis de la entidad de solicitud es correcta (por lo tanto, 400 (Malo) El código de estado de solicitud es inapropiado) pero no pudo procesar las instrucciones contenidas. Por ejemplo, esta condición de error puede ocurrir si un cuerpo de solicitud XML contiene instrucciones XML bien formadas (es decir, sintácticamente correctas) pero semánticamente erróneas ".

Answer 7

Digamos que está publicando archivos XML en un recurso, por ejemplo, de esta manera:

POST / validator Tipo de contenido: application / xml

Si la entidad de solicitud no puede analizar como el tipo de medio al que se envió (es decir, como application / xml), 400 Bad Request es el estado correcto.

Si analiza sintácticamente como el tipo de medio al que se envió, pero no valida con algún esquema deseado, o tiene una semántica que hace que no sea procesable por el recurso al que se envía, entonces 422 Entidad no procesable es el mejor estado (aunque probablemente debería acompañarlo de alguna información de error más específica en la respuesta de error, también tenga en cuenta que está técnicamente definido en una extensión a HTTP, WebDAV, aunque es ampliamente utilizado en HTTP API y más apropiado que cualquiera de los otros estados de error HTTP cuando hay una error semántico con una entidad presentada).

Si se envía como un tipo de medio que implica un esquema particular encima de xml (por ejemplo, como application / xhtml + xml), entonces puede usar 400 Bad Request si no puede validar contra ese esquema. Pero si su tipo de medio es XML simple, entonces argumentaría que el esquema no es parte del tipo de medio, aunque es un poco un área gris; si el archivo xml especifica su esquema, podría interpretar la validación como parte de los requisitos sintácticos para application / xml.

Si envía los archivos XML a través de un formulario multipart / form o application / x-www-form-urlencoded, tendrá que usar 422 Entidad no procesable para todos los problemas con el archivo XML; 400 solo sería apropiado si hay un problema sintáctico con la carga básica del formulario.