2013-05-26 13 views
10

私はASP.NET Web APIを使用して新しいREST APIを開発しています。 WCFの背景から、私はAPIの「エラー契約」を作成することに慣れています。Web APIのエラーを返す

この場合、私は未処理の例外がクライアントに返されているということではありません。代わりに、私はAPIがクライアントによって不適切に使用されている、特にクライアントが自動的にこれらのエラーを作成してリクエストを再送信できるようなエラーに集中しています。

私はちょうどより自動化された有益なエラー文字列を構築するプロセスを作るために、通常はHttpResponseExceptionを投げ、または少なくともいくつかのものをすることによって、返される文字列を持っていることがわかりました

ほとんどの例:Return custom error objects in Web API

私は」代わりにHttpResponseExceptionを作成し、その内容が特定のエラー契約タイプに設定されているHttpResponseMessageを渡すことを考えています。

また、私のAPIも自動モデル検証を多用していますが、モデル検証のエラーはまったく別の構造に戻ってきます。

「エラー」をモデル検証応答と同じ形式にする必要がありますか?ここでベストプラクティスは何ですか?

最後に、私のAPIは、json、xml、およびプロトコルバッファの書式設定オプションを公開します。その結果、私の戦略はフォーマッタに依存しないことを確かめなければなりません。

答えて

19

私はこのブログが戻ったWeb APIは、エラー処理を行う方法についてはしばらく掲示書いた:

http://blogs.msdn.com/b/youssefm/archive/2012/06/28/error-handling-in-asp-net-webapi.aspx

それは、あなたの質問に答える必要があります。基本的に、次の2つのオプションがあります。

  1. エラー応答用に独自のクラスを定義します。この場合、XML、JSONなどとしてクラスをシリアライズできるようにしたい場合は、Request.CreateResponse(statusCode, myErrorInstance)を使用してカスタムエラーを返すことができます。おそらく、無効なモデル状態を特定のエラータイプにする方法も必要です。

  2. Web APIのエラー応答タイプを使用します。HttpError。 HttpErrorは本質的にはDictionary<string, object>で、独自のキーと値をHttpErrorに追加します。メリットは多くあります。エラーはWeb APIエラーのように見えますが、すべてのフォーマッタで動作することがわかっているため、例外や無効なモデル状態からの変換を定義する必要がありません。 HttpErrorを使用する最も簡単な方法は、Request.CreateErrorResponse()です。

+0

あなたはHttpErrorとそれを返す最善の方法について何か情報を提供できますか?それはまだエラーを返す標準的な方法です - 私はそれについてほとんど気づくことはありません - thx。また、IHttpActionResultで動作するようには見えません。 – niico

1

これらの状況では、任意の操作を行うことができます。あなたのWeb APIの消費者にとって最高の経験は、間違いのない形式のjsonオブジェクトにエラーをシリアル化したい場合に、フレンドリなエラーメッセージを使用することです。次のブログ記事は、いくつかのユースケースと私が思いついた解決策を提供します:Web Api, HttpError and the Behavior of Exceptions