5

私は RESTful API を構築しており、消費者へのすべての可能な出力を制御したいと考えています。ExceptionFilterAttributeコントローラーで発生したすべての例外をフィルター処理するために を実装しています。ただし、これでは、コントローラー コードに到達する前にアプリケーションで発生する可能性のあるエラー (ルーティング エラーなど) を制御することはできません。デフォルトの動作では、標準のシリアル化された HttpError が返され、コントローラーのクラス名など、好みに合わない内部情報が多すぎます。これは避けたいと思います。この動作を変更する最良の方法は何ですか?

4

2 に答える 2

7

これを行うためにを追加できますMessageHandler。 MessageHandlersパイプラインの最初と最後に実行されるため、生の受信リクエストと生の送信レスポンスを処理できます。

例えば：

public class ErrorHandler : DelegatingHandler
{
    protected override async Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
    {
        var response = await base.SendAsync(request, cancellationToken);

        if (!response.IsSuccessStatusCode)
        {
                Debug.WriteLine("something happened! - " + response.ReasonPhrase);
        }

        return response;
    }
}

そして、あなたのGlobalConfiguration

config.MessageHandlers.Add(new ErrorHandler());

これは基本的に発信応答を検査し、ステータス コードが 2xx であるかどうかを確認します。そうでない場合は、何かを行うことができます-ログに記録するか、おそらく応答の内容をリセットして、隠したいものを非表示にします。

于 2013-01-17T18:59:08.137 に答える
3

実際、デフォルトでは、内部情報がリモートクライアントに漏洩しないように細心の注意を払っています。リクエストがデバッグ目的でローカルマシンから送信された場合、内部情報を提供しますが、リモートクライアントには送信しません。リモートクライアントの応答がどのようになるかを確認したい場合は、構成で次の設定を試してください。

config.IncludeErrorDetailPolicy = IncludeErrorDetailPolicy.Never;

WebAPIのエラー処理の詳細については、このブログ投稿も参照してください。

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

それでもデフォルトが機能しない場合は、Filipの提案に従い、メッセージハンドラーで応答をインターセプトして、好きなものを送り返す必要があります。

于 2013-01-17T19:13:42.287 に答える