アクションメソッドを[AcceptVerbs(..)]属性で既に装飾している場合、ルート定義にHttpVerb制約を登録する必要がありますか(ルートを登録する場合)?
例えば。私はこれを持っています。
[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Create(FormCollection formCollection)
{ .. }
制約として、このアクションを参照するルートにこれを追加する必要がありますか?
2つの違いは次のとおりです。問題のCreate
メソッドがHomeController
にあると仮定します。
AcceptVerbs
属性を使用しても、ルーティングには影響しません。これは実際には、アクション呼び出し元によって使用されるものです。これにより、コントローラー上に同じ名前の2つのアクションメソッドがあり、それぞれが異なるHTTPメソッドに応答します。
public ActionResult Create(int id) { .. }
[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Create(FormCollection formCollection) { .. }
したがって、/home/create
の要求が着信すると、ルートが一致し、その要求がコントローラーの呼び出し元に渡されます。次に、呼び出し側はAcceptVerbs
属性を調べて、正しいメソッドを呼び出します。
ルーティングでHttpMethodConstraint
を使用すると、ルート自体がリクエストと一致しないようになります。したがって、POSTリクエストが/home/create
に届くと、そのルートがリクエストと一致しないため、どちらのアクションメソッドも呼び出されません。別のルートwill =しかしその要求に一致します。
ここで重複する理由の一部は、ルーティングがASP.NET 3.5 SP1の機能であり、MVCに固有ではないことです。 MVCはルーティングを使用しますが、ルーティングは動的データでも使用され、ルーティングをASP.NETWebフォームと統合する予定です。
いいえ-CreateはPOSTリクエストにのみ応答します。
異なるAcceptVerb属性を持つCreateの他の実装、または他のすべての要求をキャッチする属性のない実装を持つことができます。
それが唯一のCreateメソッドである場合、GET(またはその他の非POST)リクエストは404になります。
とにかく、これはすべてルーティングエンジンによって行われていると思います。 [編集:いいえ、Haackedの投稿を参照してください]
最初にこのように飾ります:
[ActionName("ItemEdit"), AcceptVerbs(HttpVerbs.Post)]
public virtual object ItemSave(Menu sampleInput)
次に、次のようなルートを追加する必要があります。
AddRoute(
"SampleEdit",
"Admin/{sampleID}/Edit",
new { controller = "Sample", action = "ItemEdit", validateAntiForgeryToken = true },
new { areaID = new IsGuid() },
new { Namespaces = controllerNamespaces }
);