私は新しいMVC4プロジェクトを作成しています。研究の結果、JavaScriptからサーバー側への通信は、コントローラーアクションではなくWeb APIフレームワークを介して実現する方がよいと信じるようになりました。私の理解はこれで正しいですか？
私はすべての属性などをWeb APIとMVCコントローラー間で共有できると思います。そのため、一見すると、私にとって大きな変更ではないようです。
アプリケーションをセットアップするとき、コンポーネントをプロジェクトに分割したいです。私の計画は、MVCプロジェクトとWeb APIプロジェクトを用意することでした。しかし、私は問題に出くわしました。例えば、私は2つのアプリなどで終わりました、別々のルーティング設定など
だから私の質問は、MVCアプリケーションでは、Web APIフレームワークが同じプロジェクト内にあるのか、それともWeb APIを独自のプロジェクトに分離して問題を回避すべきなのか？
回答:
残念ながらあなたはそれについて間違っています- 私はすべての属性などをweb apiとmvcコントローラーの間で共有できると思いますので、一見すると、それは私にとって大きな変更ではないようです。
Web APIとMVCで使用されている概念の多くは、一見似ていても実際には互換性がありません。たとえば、Web API属性System.Web.Http.Filters.FilterとMVC属性はSystem.Web.Mvc.Filter-であり、それらは交換可能ではありません。
同じことが他の多くの概念にも当てはまります-モデルバインディング（完全に異なるメカニズム）、ルート（Web APIはルートではなくHTTPRoutesを使用しますが、両方とも同じ基になるRouteTableで動作します）、依存関係リゾルバー（互換性なし）など-表面は、実際には非常に異なります。さらに、Web APIにはエリアの概念がありません。
最終的に、JSONコンテンツを提供するための「新しい、トレンディな」方法を実現することだけが目的の場合は、その道を進む前によく考えてください。本当にHTTPを取り入れてRESTfulな方法でアプリを構築することを検討しているのでない限り、既存のコードをリファクタリングすることはお勧めしません。
それはすべて、実際に何を構築しているかに依存します。新しいプロジェクトを開始していて、必要なのは、JSONを提供してWebアプリを円滑にすることだけです-潜在的に重複する可能性のあるコード（上記のようなもの）を使用する場合は、Web APIを簡単にホストできますASP.NET MVCと同じプロジェクト。
オンラインサービス用の適切なAPIを構築する場合（おそらく外部の顧客やモバイルアプリに燃料を供給するなどのさまざまなデバイスによって消費される場合）は、Web APIを別のプロジェクトに分割するだけです。
IMO、セキュリティ、および展開が決定を推進するはずです。たとえば、MVCアプリでフォーム認証を使用していて、APIに基本認証（SSLを使用）を使用したい場合は、個別のプロジェクトを使用すると作業が楽になります。Youtサイトをwww.example.comでホストし、APIをapi.example.com（vs.www.example.com/api）としてホストする場合は、個別のプロジェクトを使用すると作業が簡単になります。プロジェクトを分離し、それに応じてサブドメインを作成し、独自のAPIをMVCアプリから利用する場合は、APIへのクライアント側呼び出しの同一生成元ポリシーの問題に対処する方法を理解する必要があります。これに対する一般的な解決策は、jsonpまたはCORSを活用することです（可能であれば）。
更新（2013年3月26日）：公式CORSサポートが提供されています：http ://aspnetwebstack.codeplex.com/wikipage?title=CORS%20support%20for%20ASP.NET%20Web%20API
ある程度の経験の後（アプリとmvcのAPIの作成）。私はほとんど両方を行います。
他のクライアントまたは他のデバイス（Android / IOSアプリ）からのAPI呼び出し用に別のプロジェクトを作成します。その理由の1つは、認証が異なるため、（ステートレスを維持するために）トークンベースであるためです。これをMVCアプリケーション内で混在させたくありません。
私のmvcアプリケーションへのjavascript / jquery api呼び出しでは、物事をシンプルに保つために、MVCアプリケーション内にWeb APIを含めます。私はjavascript api呼び出しでトークンベースの認証を行うつもりはありません。なぜなら、それは同じアプリケーションにあるからです。[authorize]APIエンドポイントで属性を使用できますが、ユーザーがログインしていないと、データを取得できません。
さらに、ショッピングカートを処理していて、ユーザーのショッピングカートをセッションに（ログインしていない状態で）保存したい場合、JavaScriptコードを使用して商品を追加/削除する場合は、これもAPIに含める必要があります。これにより、APIは確実にステートフルになりますが、MVC-APIの複雑さも軽減されます。
SimpleInjector（IoCフレームワーク）のSteven は、 2つの別々のプロジェクトに助言します：WebAPIのDependencyResolver.SetResolverとHttpConfiguration.DependencyResolverの違いは何ですか
最近、ほぼ同じことを行いました。VS2012でWeb APIテンプレートを選択する新しいMVC 4 Webアプリケーションプロジェクトから始めました。
これにより、MVCと同じアプリケーションでホストされるWeb APIが作成されます。
ApiControllersを別のクラスライブラリプロジェクトに移動したいと思いました。これはかなり簡単でしたが、解決策は少し隠されていました。
MVC 4プロジェクトのAssemblyInfo.csに、同様のコード行を追加します
[assembly: PreApplicationStartMethod(typeof(LibraryRegistrator), "Register")]ここでクラスLibraryRegistratorが必要になります（名前は自由に付けてください）。
public class LibraryRegistrator
{
public static void Register()
{
BuildManager.AddReferencedAssembly(Assembly.LoadFrom(HostingEnvironment.MapPath("~/bin/yourown.dll")));
}
}MVC 4プロジェクトでは、Apiライブラリへの参照も追加します。
これで、Apiコントローラーを独自のクラスライブラリ（yourown.dll）に追加できます。
プロジェクトが2つの「フロントエンド」を保証するほど複雑である場合でも、最後の手段として、webapiを個別のプロジェクトに分割することだけを検討します。導入の問題が発生し、初心者がソリューションの構造を理解するのが難しくなります。ルーティングの問題は言うまでもありません。
system.web名前空間を1つの「プレゼンテーションレイヤー」に分離しておくことを目指します。webapiはプレゼンテーションではありませんが、それでもアプリケーションのインターフェースの一部です。コントローラではなくドメインにロジックを保持している限り、あまり多くの問題に遭遇しないでください。また、エリアを使用することを忘れないでください。
Web.Api用に個別のDLLをセットアップすることに加えて。
ただの提案：
app_start時に呼び出されるクラスメソッドを作成します。
[アセンブリ：WebActivatorEx.PostApplicationStartMethod（typeof（API.AppWebActivator）、 "Start"）]
[アセンブリ：WebActivatorEx.ApplicationShutdownMethod（typeof（API.AppWebActivator）、 "Shutdown"）]
Startメソッド内にweb.apiルートを登録する
public static void Start（）{GlobalConfiguration.Configure（WebApiConfig.Register）; }
プロジェクトをWebプロジェクトに参照します。Startメソッドをアクティブにします。
お役に立てれば。