59

RESTful サービスを開発しており、サポートされていないすべての URL に対して 400 を返したいと考えています。

私の質問は、いつ方法 2 よりも方法 1 を選択し、その逆を選択すべきかということです。

//method 1
public ActionResult Index()
{
    //The url is unsupported
    throw new HttpException(400, "Bad Request");
}

こっちの方が良さそうですよね？

//method 2
public ActionResult Index()
{
    //The url is unsupported
    return new HttpStatusCodeResult(HttpStatusCode.BadRequest, "Bad Request");
}
4

5 に答える 5

50

2 番目の例は、最初の例と比較してマイクロコストで発生する例外のスローを含まないため、より優れているように見えます。

于 2013-06-17T13:24:47.263 に答える
13

DevOpsチームにいる私たちは皆、少しでも良い結果を得るために何かにハードウェアを投入することが常に正当な理由であるという考え方を持っています。そのため、.NET 例外を発生させるマイクロコストを意図的に無視しています。

ApplicationInsightsのようなテレメトリ フレームワークを利用している場合、ステータス コードを返すだけでは、"失敗した要求" にすぎません。失敗したリクエストの「理由」に関する情報をコンパイルまたは取得できるようにする有用な情報は提供されません。

エラー テレメトリは通常 .NET 例外に関連しているため、テレメトリ プラットフォームはユーザーがスローすることを期待し、望んでいます。スローしないと、操作に問題が生じます。

私が実際にここにたどり着いたのは、 Roslynアナライザーと CodeFix を書いている最中で、人々が書くのが大好きでtry{} catch { return BadRequest("put_the_reason_here"); }、DevOps も開発チームも ApplicationInsights のシステム テレメトリに役立つものを何も見ていないからです。

于 2015-11-25T14:47:09.440 に答える
9

私の見解では、サポートされていない URL に対してリクエストが行われたかどうかを最初に考慮する必要があります。では、それは例外的な状況だと思いますか、それとも、そうなることを期待していますか? これを例外的な状況と考える場合は、例外を作成してスローします (オプション 1)。サポートされていない URL で多くのリクエストを受信することが予想される場合は、それをアプリケーションの関数として扱い、方法 2 を使用してください。

サポートされていない URL であまりにも多くのリクエストが予想される場合は、クライアントについてもう一度考える必要があると言われています。一般に、サポートされていない URL で多くのリクエストを受信するとは思わないため、例外をスローすることを好みます。発生した場合は、例外としてログに記録し、理由を調査したいと考えています。

于 2014-03-17T18:44:58.427 に答える