2012-08-27 10 views
19

Me gustaría saber la mejor manera de gestionar la respuesta de error del servidor en los modelos nuevos, actualizados o eliminados. En este momento, el servidor devuelve un código de estado http # 400. Pero el controlador de error predeterminado en Backbone no muestra los errores.Gestión de la respuesta de error del servidor con la red troncal

¿Cómo puedo mostrar estos errores?

¿Está bien que el servidor devuelva encabezados de error HTTP cuando falla una validación del lado del servidor? (Tal vez es mejor devolver una respuesta exitosa con un mensaje de estado = 'ERROR')

Respuesta

20

Si devuelve un estado http distinto de 2XX, ya está a medio camino con el trabajo. :-) Básicamente, lo que puedes hacer es devolver todo lo que quieras como respuesta.

Por ejemplo, que sólo podría enviar de vuelta algo como esto:

// Send back http status 500 
echo 'Could not save, server error'; 

El estado 500 disparará la respuesta de error Backbone y su respuesta es un objeto jqXHR. En el ejemplo anterior, puede obtener el mensaje haciendo algo como esto en su devolución de llamada por error.

model.save({},{ 
    error: function(model, response) { 
     console.log(response.responseText); 
    } 
}); 

Esta es la forma más sencilla de recuperar algunos datos/mensajes sobre el error que ocurrió en el servidor. Puede, por supuesto, crear datos más sofisticados para ser devueltos desde el servidor:

// I'm using SLIM RESTful framework... 
$dataOut = array('error'=>'Validation type', 'message'=>'Did not validate'); 
$response->body(json_encode($dataOut)); 

De la misma manera, puede acceder a que la respuesta de este modo:

model.save({},{ 
    error: function(model, response) { 
     var responseObj = $.parseJSON(response.responseText); 
     console.log('Type: ' + responseObj.error + ' Message: ' + responseObj.message); 
    } 
}); 

O algo por el estilo.

Debido a la respuesta pasa en su respuesta de error es el objeto jqXHR, usted tiene acceso completo a todas sus propiedades que es posible que desee utilizar:

E.g. 
response.readyState 
response.status 
response.statusText // etc. 

Backbone sólo necesita el estado HTTP devuelto por el servidor para hacer su cosa

+0

Hoy me estoy enfrentando a este problema. Aquí está la pregunta: si mi API SLIM RESTful es (teóricamente) capaz de ser utilizada por clientes que no sean clientes web (por ejemplo, iOS, etc.), ¿está bien si SLIM está devolviendo códigos de estado HTTP no 200 en circunstancias como esta? Las situaciones descritas anteriormente (por ejemplo, errores de validación de formulario, etc.) posiblemente no sean un error del servidor, sino que el servidor responda correctamente a una mala entrada del usuario. – hairbo

+1

Creo que tu comentario es de 2 partes. 1) ¿Debería SLIM devolver códigos de estado http que no son 200? Me imagino que sí, ya que no puedo ver cómo sería posible herir al hacerlo. Muchas cosas del lado del cliente se basan en ese código de estado para ejecutar devoluciones exitosas o de errores. 2) ¿Es el estado 500 apropiado para la validación? No. En mi ejemplo, acabo de crear un problema que era un servidor para guardar. Supongo que si estás haciendo una validación del lado del servidor, una solicitud incorrecta de 400 podría ser una buena opción. – jmk2142

+0

No estoy seguro de que estuviera sugiriendo 5xx para los errores de validación, pero ese no es realmente el problema. Creo que estoy siendo un poco exigente, pero los códigos de error del servidor sugieren (para mí, de todos modos) que algo ha ido mal con el * servidor *. Un error de validación realmente es que el servidor responde correctamente a los datos incorrectos del * cliente *. Entonces, en cierto nivel, responder con un 4xx a los datos del cliente malo parece ser incorrecto. Sin embargo, el mundo entero lo está haciendo de esta manera, y no voy a luchar contra el mundo entero en ese punto. (-; – hairbo

Cuestiones relacionadas