2011-07-15 22 views
6

Estoy creando una función de mi aplicación web en la que un usuario puede "editar in situ" un registro y enviar el formulario a través de AJAX utilizando jQuery.¿Qué código de respuesta/estado debo enviar a una solicitud AJAX cuando hay un error de validación de usuario/formulario?

Cuando alguien está "editando ajax" un registro y envían el formulario con datos válidos, envío un código de estado 200, que desencadena la función jQuery AJAX Success, luego ignora el cuerpo de la respuesta (ya que fue exitoso, yo don no lo necesita), y colapsar la forma.

Cuando hay errores de validación de formulario, envío un código de estado 400 para activar el método de error jQuery, y en el cuerpo de la solicitud especifico qué campos no validaron.

En una pregunta anterior de StackOverflow, alguien mencionó que "parecía extraño" que estuviera enviando un código de estado de 400 y trabajando con el cuerpo de la respuesta. ¿Mi enfoque no es una mejor práctica? ¿Qué recomendarías que haga en esta situación?

Respuesta

4

El uso de la carga de un código de estado 4xx está bien. No hay nada en la especificación HTTP que diga lo contrario.

Si quiere algo más específico que 400, eche un vistazo a 422 Unprocessable Entity.

+1

Ooooh, me gusta 422. –

+0

Los códigos de estado son en realidad para comunicar metadatos sobre la solicitud entre el cliente y el servidor, no entre la aplicación y el servidor. –

+1

422 es también una extensión WebDAV para el protocolo HTTP, que no forma parte del protocolo original. Tendría sentido usar este código de estado con un servicio WebDAV. –

6

Para mí, los códigos de estado HTTP son para la señalización en la capa HTTP, no en la capa de aplicación. Diría que la respuesta adecuada a los datos incorrectos enviados correctamente (si ves lo que quiero decir) es un 200 con un código de error de capa de aplicación. Yo uso JSON para esto. Mis solicitudes siempre reciben un pequeño mensaje JSON, que siempre tiene un indicador que indica éxito/falla en el nivel de la aplicación. Mis contenedores para llamadas ajax lo saben y lo envían según corresponda.

+0

buen punto. así es tu json tipo de esto: {success: 0, html: 'los mensajes de error van aquí'} – Andrew

+1

@Andrew: Sí, o '{" error ":" "}' en caso de éxito y '{" error ":" Non sequitur. Sus hechos no están coordinados. "}' En error. Entonces mi código del lado del cliente es 'if (message.error) {/ * ... informe de error * /}' –

+2

No estoy de acuerdo. En las interfaces de estilo REST, los códigos de respuesta son para la señalización a nivel de la aplicación. Piense en las operaciones de CRUD donde regresa, digamos 201 CREADO en un POST. En este caso, un 400 no es una mala forma de señalar datos formateados incorrectamente. –

-1

Devolvería 200 con una página de error (de la aplicación) o la página original con una opción de error, que desencadena un panel informativo con la descripción del error.

La razón de esto es que los códigos de error HTTP son para la respuesta del del navegador al servidor web, no para su aplicación web. Mantenga la lógica de su aplicación separada de lo que sucede cuando el navegador y el servidor se comunican entre sí.

+0

Los códigos de estado son independientes del tipo de cliente. –

+0

Considere que tiene su aplicación principal, que a su vez contiene dos aplicaciones: 1. Una aplicación JS completa que consumirá su segunda aplicación. 2. Una API que será consumida por su aplicación JS. ¿Por qué no usar los códigos de respuesta HTTP para manejar devoluciones de llamadas exitosas o de error? ¿Qué pasa si más clientes comienzan a consumir su segunda aplicación? Si ese fuera el caso y usted comenzó a enviar correctamente los códigos de respuesta HTTP desde el inicio, entonces no tendría que refactorizar las respuestas de su API. Mi punto aquí es que no hace daño usar diferentes códigos de respuesta HTTP. ¿Qué piensas? – chischaschos

Cuestiones relacionadas