20

私はプロジェクトに取り組んでおり、アカウントの詳細の更新、新しい詳細の追加、ASP.NET Web ApiとBackbone.jsで行われたすべての変更など、すべてのクライアント側の操作をWebAPIに大きく依存しています。

現在のシーン：

現在のスキームでは、操作が成功したかどうかを示すために、WebAPIコントローラーからブール値を返しています。

例 ：

[ActionName("UpdateAccountDetails")]
public bool PostAccountDetails(SomeModel model)
{
    bool updateStatus = _customService.UpdateAccountDetails(model);
    return updateStatus;
}

そのため、このアクションに対してajax呼び出しを行った後、応答にtrue / falseがないかチェックし、エラーまたは成功メッセージを表示します。

問題 ：

ここで何が起こったのかというと、アクションで例外が発生し始め、アクションがfalseを返し続け、エラーメッセージが表示されました。しかし、私は理由を見つけることができませんでしたか？

だから私は誰もが従う標準的なAPI応答構造があるかどうか疑問に思いましたか？

私は当初、このクラスを返すために各WebAPIアクションを使用するというこのアイデアを思いつきました。

public class OperationStatus
{
    public bool Result { get; set; } // true/false
    public string Status { get; set; } // success/failure/warning
    public List<string> WarningMessages { get; set; }
    public List<string> ErrorMessages { get; set; }
    public string OtherDetails { get; set; }
}

この変更は大きな変更であり、時間とリソースを消費するので、これについて2番目/3番目/4番目の意見を持っている方が良いと思いました。

これについて考えてみてください。

アップデート ：

マークジョーンズの少しの助けを借りて、私はこれを思いついた

[ActionName("UpdateAccountDetails")]
public HttpResponseMessage PostAccountDetails(SomeModel model)
{
    bool updateStatus;
    string errorMessage;
    try{
        updateStatus = _customService.UpdateAccountDetails(model);
        if(updateStatus)
        {
            return Request.CreateResponse(HttpStatusCode.OK);
        }
        return Request.CreateResponse(HttpStatusCode.InternalServerError);
    }
    catch(Exception exception)
    {
        errorMessage = exception.Message;
        return Request.CreateResponse(HttpStatusCode.InternalServerError, errorMessage);
    }

    return updateStatus;
}

これについて何か考えはありますか？

4

2 に答える 2

26

コントローラーのアクションで try/catch を使用しないでください。

あなたの問題を処理する方法はたくさんあります。最も単純で最もクリーンな解決策は、おそらく an を使用しActionFilterて例外を処理することです。次のようなものです。

public class ExceptionAttribute : ExceptionFilterAttribute
{
    public override void OnException(HttpActionExecutedContext context)
    {
        Debug.WriteLine(context.Exception);

        throw new HttpResponseException(new HttpResponseMessage(HttpStatusCode.InternalServerError)
        {
            Content = new StringContent("An error occurred!"),
            ReasonPhrase = "Deadly Exception"
        });
    }
}

次に、アクションを で装飾するだけです[ExceptionAttribute]。もちろん、ビジネス例外、データ例外、IO 例外など、さまざまな種類の例外に対して異なる動作をするように拡張し、それに基づいてさまざまなステータス コードとフィードバックを返すこともできます。

Fredrik Normen による優れた記事「ASP.NET Web API Exception Handling」 を読むことをお勧めしますhttp://weblogs.asp.net/fredriknormen/archive/2012/06/11/asp-net-web-api-exception-取り扱い.aspx。

彼は、Web API の例外処理手法の優れた概要を提供しています。

于 2012-12-19T15:29:50.083 に答える
4

HttpResponseMessageを返す代わりに、API を同じままにして、例外をキャッチしたときにHttpResponseExceptionをスローします。このようなもの：

throw new HttpResponseException(
    new HttpResponseMessage(HttpStatusCode.InternalServerError) 
       { ReasonPhrase = errorMessage });

この方法では、API の定義を変更せず、シリアル化する必要のあるオブジェクトを返す GET アクションでも機能します。JQuery ajax メソッドを使用してリクエストを送信している場合、エラーハンドラーはこれをキャッチし、errorThrownパラメーターでテキスト メッセージを取得し、それに応じて処理できます。

于 2012-12-19T14:17:39.337 に答える