2XX以外のHTTPステータスを返している場合は、すでに半分で完了しています。 :-)基本的に、あなたができることは、あなたが返信したいものを返信することです。
// Send back http status 500
echo 'Could not save, server error';
500のステータスがバックボーンエラーコールバックをトリガすると、あなたの応答がjqXHRオブジェクトです:
はたとえば、あなただけのこのような何かを送り返すかもしれません。上の例では、エラーコールバックでこのようなことをしてメッセージを得ることができます。
model.save({},{
error: function(model, response) {
console.log(response.responseText);
}
});
これは、サーバー側で発生したエラーに関するいくつかのデータ/メッセージを取り戻す最も簡単な方法です。もちろん、サーバから返されるより洗練されたデータを作成することができます。これらの線に沿って
model.save({},{
error: function(model, response) {
var responseObj = $.parseJSON(response.responseText);
console.log('Type: ' + responseObj.error + ' Message: ' + responseObj.message);
}
});
か何か:
// I'm using SLIM RESTful framework...
$dataOut = array('error'=>'Validation type', 'message'=>'Did not validate');
$response->body(json_encode($dataOut));
同じやり方で、あなたはそうのようなその応答にアクセスすることができます。
あなたのエラーコールバックに渡された応答がjqXHRオブジェクトなので、あなたが使用することをお勧めしますそのすべてのプロパティへのフルアクセスを持っている:
E.g.
response.readyState
response.status
response.statusText // etc.
バックボーンのみ、サーバから返されたHTTPステータスを必要としますそのことをする。
私は今日、この問題に直面しています。 SLIM RESTful APIがウェブクライアント(iOSなど)以外のクライアントでも(理論的に)使用できる場合は、SLIMがこのような状況で200以外のHTTPステータスコードを返すのは問題ありませんか?上記の状況(フォーム検証エラーなど)は、間違いなくサーバーエラーではなく、むしろ悪いユーザー入力に適切に応答するサーバーです。 – hairbo
あなたのコメントは2部だと思います。 1)SLIMが200以外のHTTPステータスコードを返すべきか?私はそうすることによってどのように傷つく可能性があるかわかりませんので、私はそう思っています。多くのクライアントサイドのものは、成功またはエラーのコールバックを実行するためにそのステータスコードに依存しています。 2)ステータス500は検証に適していますか?いいえ、私の例では、私はちょうど節約のためのサーバーであった問題を作りました。私はあなたがサーバー側の検証を行っているかどうか、400悪い要求が良い選択かもしれないと思います。 – jmk2142
私は5xxに検証エラーを示唆していましたが、それは実際問題ではありません。私はちょうど執拗になっていると思うけど、サーバーのエラーコードは、何かが* server *に間違っていることを(私にはとにかく)示唆している。検証エラーは、実際には*クライアント*からの不正なデータに正しく応答するサーバーです。したがって、あるレベルでは、不正なクライアントデータに4xxで応答すると間違っているようです。しかし、世界全体がこのようにしており、私はその時点で全世界と戦うつもりはない。 ( - ; – hairbo