クライアント スクリプトが重い ASP.NET MVC アプリケーションを構築しています。JSON と jQuery を使用して DOM を操作します。
私の理解では、Web API コントローラーとMVC コントローラーの両方が JSON を返すことができます。
私のシナリオでは、Web API ControllerまたはMVC Controllerを使用する必要がありますか?
クライアント スクリプトが重い ASP.NET MVC アプリケーションを構築しています。JSON と jQuery を使用して DOM を操作します。
私の理解では、Web API コントローラーとMVC コントローラーの両方が JSON を返すことができます。
私のシナリオでは、Web API ControllerまたはMVC Controllerを使用する必要がありますか?
Web API コントローラーは、MVC アプリケーションだけでなく、任意の ASP.NET アプリケーションで作成およびホストできます。したがって、Web API を作成する明白な理由は、MVC フロントエンドがない場合です (たとえば、会社/組織がホストする従来の RESTful Web サービス)。
MVC コントローラーは通常、MVC フレームワークに依存しています。既定のテンプレートと、コミュニティや仲間によって行われたほとんどの作業を見ると、ほとんどすべての MVC コントローラーがビューを念頭に置いて実装されていることがわかります。
個人的には、View() で応答する場合は MVC コントローラーを使用し、特定のビューに依存しないものには Web API を使用します。
もちろん注意点はありますが、一般的に言えば、MVC のモデル バインディング動作を必要とせず、サービスがデータ中心で、操作がデータ中心 (CRUD 操作など) である場合は、「Web API コントローラー」が必要になる可能性があります。 'Model-View Controller' の代わりに。逆に、操作がビュー中心の場合 (ユーザー管理ページをユーザーに配信するなど)、または「ajax パーシャル」を生成するために MVC のモデル バインディングが必要な場合 (ほとんどありません)、代わりに MVC コントローラーが必要になります。
個人的には、Web API コントローラーを使用して JSON ベースの RESTful クライアントを駆動し、MVC コントローラーを使用して基本的なブラウザー ルーティングと SPA の配信を処理します。
WebAPIはAPIを作成するためのものです。誰かがあなたのAPIをXMLやJSONなどで利用できるようにしたい場合は、WebAPIを作成できます。
あなたの場合、JSONでクライアントと話すだけで済みます。
Webサイトのほとんどがクライアントスクリプト駆動型ですが、ASP.NET MVCコントローラーを使用していますか?また、エンティティに基づいてコントローラをすでに論理的に分割している可能性があるため、Web API専用の別のクラスを作成するのではなく、それらのjsonサービングメソッドを追加することは理にかなっています。
だからあなたの特定の状況(私が正しく理解しているなら)のために、私はコントローラーに固執するでしょう。
答えは、問題の分離、サービスの作成の迅速化、および構成ではなく規則に依存することです。
コントローラーの主な責任は、ビューとモデルの間のコーディネーターとして機能することですが、API の主な責任はデータを操作することです。API の規則の場合、CRUD 操作を非常に簡単に実行できます。以下は、CRUD 操作と HTTP アクションの間のマッピングです。
したがって、API を使用すると、個別のアクションを作成して HTTP アクションに関連付ける必要はありません。
私はショーン・ウィルソンの(トップアンサー)の答えに同意しますが、少し混乱していて、次の(おそらく間違っている)予感で理解しようとしているため、理由はわかりません-
Shaun の回答の最後の行に「基本的なブラウザー ルーティングと SPA の配信を処理するために MVC コントローラーを使用しています」と記載されているため、ここでどのように間違っているのかわかりません。-おそらく、JSON形式で応答を受け取るJavaScriptメソッドである可能性があると想定したとき、安らかなクライアントが何であるかを完全には知りません。これは、私の質問への回答としてリモートで関連した Stackoverflow で最も近い投稿であるため、質問を複製する代わりに、この投稿に回答しています。