En mi código del lado del cliente, compruebo la presencia del atributo de errores y reacciono según sea necesario.
Por ejemplo, estaba usando la función Collection.create, que llama a la función de agregar de la Colección si la solicitud fue exitosa. Por lo tanto, anulé la función de agregar de mi colección para evitar que se agregue el modelo si tiene un atributo 'errores' y si no llama al método "super".
add: function(object, options) {
if (_.isArray(object) || !object.get('errors')) {
Backbone.Collection.prototype.add.call(this, object, options)
}
},
Tener mi aplicación de vuelta un código de estado de no éxito también funcionaría, ya que impide que se ejecuten las devoluciones de llamadas exitosas. Pero no me gustó la idea de devolver un error 400 solo porque el envío no era válido. Eso es algo que nunca he tenido que hacer en aplicaciones que no sean Backbone.js. ("Invertebrados"?)
Ninguna de las descripciones para los códigos de estado 4XX parecían realmente coincidían con el concepto de validación fallida. 400 y 403 se acercan, pero aún salen como si fueran para otros usos. Por otro lado, al usuario realmente no le importa qué código de estado devuelve; bien podría ser un 404.
Es realmente una cuestión de si desea escribir más código del lado del servidor o del lado del cliente. Mi aplicación más o menos ignora el resultado de la validación y devuelve el registro serializado a JSON, ya sea que se haya guardado o no, así que elegí trabajar desde ese ángulo.
¿No debería ser un 400 (Solicitud incorrecta) en lugar de un 403 (Prohibido)? Normalmente he visto 403 utilizado cuando un usuario intenta acceder a un recurso al que no tiene permiso de acceso. –
Creo que esto debería ser 422 (entidad no procesable); porque los datos enviados no son válidos, no se pudieron procesar. – sockmonk