0

WebAPI の前は、通常の MVC アクション メソッドを使用して、すべてのクライアント側のリモート検証呼び出しを行っていました。WebAPI を使用すると、ApiController で POST、PUT、DELETE、および GET メソッドを使用できるようになりました。ただし、検証はまだ行う必要があります。

リモート検証アクション メソッドを ApiController に配置し、動作させることができました。リソースの POST、PUT、または DELETE を送信する前に、クライアントは 1 つ以上の検証 URL に POST して、ユーザー入力を検証し、適切な検証メッセージを受け取ることができます。

私の質問は、これらのリモート検証アクションは ApiController で行うべきですか? それとも通常の MVC コントローラーですか? それらをすべて ApiController に入れるのが最も理にかなっているように思えます。そのクラスは、リソース (およびリソース コレクション) のミューテーションに関係するすべてをカプセル化できるからです。

更新: @tugberk に返信

詳しく説明する必要があります。まず、DataAnnotations 検証を使用していません。FluentValidation.NET を使用して、ドメイン層コマンドで構成された豊富な検証ルールとメッセージが既にあります。検証クラスの多くは、依存性注入を使用してデータベースを呼び出します (たとえば、一意性を検証するため)。FluentValidation は MVC ModelState との優れたプラグ可能性を備えていますが、WebAPI ModelState にプラグインする良い方法をまだ見つけていません。

次に、POST、PUT、および DELETE エンドポイントで検証を行っています。クライアントは、何が問題なのかを発見するために検証エンドポイントを知る必要はありません。次に例を示します。

var command = Mapper.Map<CreateCarCommand>(carApiModel);
try
{
    _createHandler.Handle(command);
}
catch (ValidationException ex)
{
    return Request.CreateResponse(HttpStatusCode.BadRequest, ex.Message);
}

クライアントは、400 応答と、何が問題であったかを示すメッセージを受け取ります。確かに、これはリンク先の例の応答ほど詳細ではありません。文字列を返すだけなので、各検証メッセージが属するフィールドを解析する簡単な方法はありません。これは、API の独自の HTML + JavaScript クライアントに必要です。これが、私がより詳細な検証エンドポイントを追加した理由です (ちなみに、これらは JavaScript クライアントでのフィールド固有のノックアウト検証呼び出しによって消費されます)。

4

1 に答える 1

0

remote validationと言うことで、ASP.NET MVC Remote Validation に似たものを参照していると思います。その場合、HTTP API にリモート検証は必要ないと思います。HTTP API を .NET アプリケーションで使用する必要があり、リモート検証があると仮定するシナリオを考えてみてください。ここで2つのことが気になります：

  1. そのリモート検証は、API 用の .NET クライアントを自分で提供し、そのロジックをそのクライアント内に配置しない限り、検出できません。
  2. .NET クライアント用のリモート検証があり、アプリケーションが実際の要求を送信する前にサーバーに対して検証呼び出しを行うと仮定すると、これはやり過ぎです。

私の意見では、ユーザーは API にリクエストを送信し、そこで検証を行う必要があります。次の URL からサンプルを見つけることができます。

ASP.NET Web API と ModelState 検証の処理

于 2012-10-31T11:49:55.997 に答える