Se si restituisce uno stato http diverso da 2XX, si è già a metà del lavoro. :-) Fondamentalmente, quello che puoi fare è rimandare tutto ciò che vuoi come risposta.
Per esempio, si potrebbe semplicemente rimandano qualcosa di simile:
// Send back http status 500
echo 'Could not save, server error';
Lo stato 500 attiverà il callback errore Backbone e la vostra risposta è un oggetto jqXHR. Nell'esempio sopra puoi ottenere il messaggio facendo qualcosa di simile nel tuo callback di errore.
model.save({},{
error: function(model, response) {
console.log(response.responseText);
}
});
Questo è il modo più semplice per recuperare alcuni dati/messaggi sull'errore verificatosi sul lato server. Naturalmente, è possibile, creare dati più sofisticati per essere restituiti dal server:
// I'm using SLIM RESTful framework...
$dataOut = array('error'=>'Validation type', 'message'=>'Did not validate');
$response->body(json_encode($dataOut));
Allo stesso modo, è possibile accedere a tale risposta in questo modo:
model.save({},{
error: function(model, response) {
var responseObj = $.parseJSON(response.responseText);
console.log('Type: ' + responseObj.error + ' Message: ' + responseObj.message);
}
});
O qualcosa del genere.
perché la risposta passato nella tua callback errore è l'oggetto jqXHR, si ha pieno accesso a tutte le sue proprietà che è possibile utilizzare:
E.g.
response.readyState
response.status
response.statusText // etc.
Backbone ha bisogno solo lo stato HTTP restituito dal server fare la sua cosa
Sto affrontando questo problema proprio oggi, in realtà. Ecco la domanda: se la mia API RESTful SLIM è (teoricamente) in grado di essere utilizzata da client diversi dal client Web (ad esempio iOS, ecc.), Allora va bene se SLIM restituisce codici di stato HTTP non 200 in circostanze come questa? Le situazioni descritte sopra (ad esempio errori di convalida del modulo, ecc.) Non sono probabilmente un errore del server, ma piuttosto il server risponde correttamente all'input utente errato. – hairbo
Penso che il tuo commento sia di 2 parti. 1) SLIM dovrebbe restituire codici di stato http non-200? Immagino di sì, perché non riesco a vedere come sarebbe possibile ferirlo facendo così. Un sacco di cose sul lato client si basa su quel codice di stato per eseguire callback di successo o di errore. 2) Lo stato 500 è appropriato per la convalida? No. Nel mio esempio, ho appena creato un problema che era un server per il salvataggio. Immagino che se stai facendo la convalida sul lato server, una 400 cattiva richiesta potrebbe essere una buona scelta. – jmk2142
Non sono sicuro che stavo suggerendo 5xx per errori di validazione, ma non è proprio questo il problema. Penso di essere solo un pignolo, ma i codici di errore del server suggeriscono (per me, comunque) che qualcosa è andato storto con il * server *. Un errore di convalida è in realtà il server che risponde correttamente ai dati non validi dal * client *. Quindi a un certo livello, rispondere con un 4xx a dati di client non validi sembra sbagliato. Comunque, il mondo intero lo sta facendo in questo modo, e io non ho intenzione di combattere il mondo intero su quel punto. (-; – hairbo