RESTfulサービスとさまざまなクライアント（Silverlight、iOS、Windows Phone 7など）で構成される分散アプリケーションを設計しています。現在、サービス、WCFデータサービス（OData）、またはASP.NET MVC 4で提供される新しいASP.NET Web APIを実装するために使用する必要があるテクノロジを決定しています。
私はそれぞれについていくつかのプレゼンテーションをオンラインで見てきましたが、今は主にURIとネイティブハイパーメディア機能に組み込まれているフィルタリングメカニズムのために、WCF Data Servicesに傾いています。私が見ることができる唯一の欠点は、POXとは対照的なAtom Pub仕様の冗長性です。
決定を下す前に、これら2つのテクノロジーについて知っておくべきことはありますか？なぜ誰かがWCF Data ServicesではなくASP.NET Web APIを選択するのですか？
回答:
これは主観的な質問なので、主観的な答えを示します。IMO、WCFは単純なRESTfulサービスにはオーバーヘッドが大きすぎます。一方、Web APIはRESTfulサービス用に特別に設計されました。
私はこれに関してデイブ・ウォードに同意します。詳細については、彼のブログをご覧ください。
私は長い間、WebFormsプロジェクトでASMXからWCFに移行するというプレッシャーに反対してきました。WCFの複雑さを受け入れることは、主に柔軟性の低いJSONシリアライゼーションでしか報酬が得られないからです。対照的に、私のプロジェクトのいくつかをASMXからWeb APIに変換し始めており、Web APIがASMXをどれほど簡単に置き換えることができるかに満足しています。
マイクロソフトは、ASMXのシンプルさとWeb APIでのWCFの能力のバランスがとれたことをようやく見出しました。
MediaTypeFormatter応答をフォーマットするために実装できるようです。サンプルについては、code.msdn.microsoft.com / Contact-Manager-Web-API-0e8e373dを参照してください。
現在、WebApiとWCF Data Servicesの間には他の大きな違いがありますが、誰も言及していないようです。MSが2つを比較する良い記事を出してくれるといいのですが。
私はしばらくの間ODataとWebApiをフォローしています。私はいつもいくつかの大きな違いを見つけました。
まず、上司が「MSがWebApiをサポートしている」とは、ODataをサポートしていないという意味ですか？IMO、彼らは両方を支持しており、現在いくつかの最小限の重複があります。Windows AzureデータマーケットはODataを使用してデータを公開し、Azure Table StorageはODataを使用し、SharePoint 2010はそのデータに対するODataクエリを許可し、MSの他の製品（Excel PowerPivotなど）もサポートしています。リレーショナルデータに関しては、非常に強力なクエリフレームワークです。また、RESTfulであるため、あらゆる言語、フレームワーク、デバイスなどを統合できます。
OData + WCF Data Servicesについて私が気に入っている点は次のとおりです。
OData + WCF Data Servicesは、Web経由でデータをクエリするときに、クライアントアプリケーションをより「表現力のある」ものにすることができるようになりました。以前は、常にASMXまたはWCFを使用して、手に負えず、UIが少し異なるものを必要とする場合は常に変更を必要とする堅固なWeb APIを構築する必要がありました。クライアントアプリケーションは、返す条件を指定するパラメーターのみを指定できます。または、私が行ったようにしてLINQ式を「シリアル化」し、それらをパラメーターとして渡しExpressions<Func<T,bool>>て、サーバーに再水和します。そのまともな。仕事は終わりましたが、クライアントでLINQを使用し、RESTを使用してWeb経由で変換させたいと思います。これは、ODataが許可するものであり、ソリューションの独自の「ハック」を使用したくありません。
これは、DB接続文字列を必要とせずに「TRANSACT SQL」を公開するようなものです。単にURLとwhoalaを提供してください！クエリを開始します。もちろん、WebApiとWCF Data Servicesはどちらも認証/承認をサポートしているため、アクセスを制御したり、役割やその他のデータ構成に基づいて「Where」ステートメントを追加したりできます。SQLではなく、Web APIレイヤーでこれを行います（ビューの作成やストアドプロシージャなど）。アプリケーションがクエリを自分で作成できるようになったので、アドホックツールとBIレポートツールがODataを活用し始め、ユーザーが独自の結果を定義できるようになります。最小限の制御しか持たない静的レポートに依存しない。
Silverlight、Windows 8 Metro、またはASP.NET（MVC、WebFormsなど）で開発する場合、Visual Studioの「サービス参照」をWCFデータサービスに追加するだけで、LINQを使用してデータをクエリし、データを取得できます。クライアント上の「データコンテキスト」。つまり、変更を追跡し、変更を「送信」してサーバーにアトミックに戻すことができます。これは、RIA Services for Silverlightに非常によく似ています。私はRIAサービスの代わりにWCFデータサービスを使用していましたが、当時はDataAnnotationsまたはActionsをサポートしていませんでしたが、現在はサポートしています:) WCFデータサービスには、RIAサービスよりも「プロジェクション」を実行できるという利点があります。クライアントから。これは、エンティティからすべてのプロパティを返したくない場合に、パフォーマンスに役立ちます。「データコンテキスト」を持つ
そのため、特にSQL ServerとEntity Frameworkを使用している場合に、関係を持つデータがある場合、WCF Data Servicesは優れています。非常に少ないコードで、RESTを介してクエリ可能なデータ+アクション（操作を呼び出すための呼び出し、つまりワークフロー、バックグラウンドプロセス）をすばやく公開できます。WCF Data Servicesが更新されました。新しいリリースがリリースされました。すべての新機能をチェックしてください。
WCF Data Servicesのマイナス面は、HTTPスタックから解放される「コントロール」です。最大の欠陥は、IQueryable<T>コレクションを返すメソッドにあることがわかりました。RIA Services AND WebApiとは異なり、IQueryableメソッドでロジックを開発するための完全なアクセス権はありません。RIAサービスとWebApiでは、戻って来る限り、好きなコードを書くことができますIQueryable<T>。WCF Data Servicesでは、Expression<Func<T,bool>>インターセプターメソッドを使用して「Where」ステートメントを追加するアクセス権のみを取得します。これはがっかりした。現在のアプリケーションはRIAサービスを使用しており、IQueryableロジックを制御する機能が本当に必要であることがわかりました。私はこれについて間違っていて、私は何かを逃していると思います
また、WCF Data Servicesは、まだすべてのLINQオペレーターを完全にはサポートしていません。ただし、WebApi以外にもサポートしています。
WebApiはどうですか???
今のところ（私の理解では）、WebApiはWCFデータサービス/ ODataのようなエンティティデータモデルを対象としていないため、クライアント（つまり、Silverlight、ASP.NETサーバー側コードなど）では「データコンテキスト」サポートがありません。です。IQueryable / IEnumerableを使用してモデルオブジェクトのコレクションを公開できますが、「データコンテキスト」がないため、エンティティがクライアントに読み込まれると使用する主キー/外部キー「ナビゲーションプロパティ」（つまり、customer.Invoices）はありません。非同期で（または$ expandを使用した1回の呼び出しで）それらをロードし、変更を管理します。RIAサービスやWCFデータサービスのように、クライアントでエンティティデータモデルのコード生成された「表現」がありません。データを表すモデルをクライアントに含めることはできません。ただし、データを手動で入力し、Web経由で取得した各「顧客」に設定する「請求書」を管理する必要があります。これは、特にAsyncに関するすべての処理が行われている場合、注意が必要です。どの通話が最初に戻るかわかりません。これをここで説明するのは難しいかもしれませんが、RIAサービスの「データコンテキスト」に関する情報を読んだり、WCFデータサービス。基幹業務アプリを扱う場合、これは私にとって大きな問題です。これは主に生産性と保守性に基づいています。データコンテキストがなくても、一時的にアプリを構築できます。特に、Silverlight、WPF、そして今ではWindows 8 Metroで、物事がより簡単になります。リレーショナルエンティティを非同期でメモリにロードし、Two-Bindingを用意しておくと、とても便利です。
とはいえ、これはいつかWebApiがクライアントで「データコンテキスト」をサポートできることを意味しますか？できると思います。また、より多くのツールを使用して、Visual Studioプロジェクトはデータベーススキーマ（またはエンティティフレームワーク）に基づいてすべてのCRUDメソッドを生成できます。
また、WCF Data ServicesまたはWebApiでの作業に関しては、.NETから.NET Frameworksについてのみ言及していることは承知していますが、HTML / JSも主要なプレーヤーであることをよく認識しています。Silverlight UI、またはASP.NETサーバー側コードなどを処理するときに見つけた利点について言及しました。「データコンテキスト」とJavaScriptのLINQフレームワークも利用できるようになり、JavaScriptからODataサービスへのクエリ機能がさらに簡単になります（ODataで現在DataJSを使用できます）。さらに、KnockoutJSを使用してMVVMをサポートし、HTML / JSでのバインディングもサポートすることで、それが簡単になります。
現在、使用するプラットフォームを調査しています。どちらを使用してもかまいませんが、次のアプリケーションは主にアナリティクス（読み取り専用）を対象としているため、表現力豊かなRESTful APIが必要なので、ODataに傾く傾向があります。私はOData + WCF Data Servicesが私にそれを与えると信じています。WebApiはコレクションに対して$ take、$ skip、$ filter、$ orderbyのみをサポートしているからです。プロジェクション、インクルード（$ expand）などはサポートしていません。「更新/削除/挿入」があまりなく、データはかなり関係があります。
他の人も議論に参加して、彼らの考えを述べてほしい。私はまだ決定中であり、他の意見を聞きたいです。どちらも素晴らしいフレームワークだと思います。選択する必要があるのではないかと思うので、必要に応じて両方を使用してみませんか。クライアントからは、とにかくREST呼び出しを構築することがすべてです。ちょっとした考え ：）
Web APIは、今後のODataサービスに適切なプラットフォームを提供し、その ため、主に ODataサーバースタックのプラットフォームに投資すると考えています。もちろん、ODataコアライブラリとクライアントに重要なリソースを引き続き投入しますが、ODataサービスを作成するためのスタックとしてWCF Data Servicesへの投資を削減する予定 です。
だから、今ではすべてが十分にはっきりしているようです
Web APIとWCF Data Servicesはどちらも、そのままでODataをサポートしています。WCF Data Services（WCFDS）を使用すると、自動的に行われます。Web APIを使用して、IQueryableコントローラーから戻り、メソッドにタグを付けます[Queryable]。これは$filterあなたが話していた機能性を手に入れます。そして、この方法でこれを行うaccept=application/jsonと、リクエストヘッダーを挿入することで、どちらもレスポンスのJSONを自動的に処理できます。WCFDSのODataは、Web APIよりもいくつかのODataキーワードをサポートしています（ただし、$expandキーワードだけが頭に浮かびます）が、時間をかけてこれを修正すると確信しています。
.NETクライアントとHTMLページの両方がこれらの代替手段の両方を簡単に呼び出すことができますが、LINQが好きで、.NETクライアントを構築している場合は、WCFDSをサービス参照としてプロジェクトに追加できます。これにより、すべてのHTTPビジネスをスキップして、コレクションに直接クエリを実行できます。
結論として、.svcファイルをASP.Net MVCプロジェクトに配置することを妨げるものは何もありません。それはどちらか一方の命題ではありません。サーバーにデータサービスを追加すると、多数のコントローラーを作成する必要がなくなりますが、必要に応じて追加のコントローラーを作成することはできます。
言い換えると ：
データモデル（EDMなど）をすばやく公開し、多くのコードやビジネスロジックを必要としない場合は、WCF Data Servicesを使用すると非常に簡単になり、優れた出発点になります。
APIを構築していて、ODataクエリ構文またはフォーマットのいずれかを使用して一部のリソース（およびロジック）を公開するだけの場合は、ASP.NET Web APIが開始するのに最適です。
Devaronは、私がまだ見つけていないWCFとWeb Apiの最も有益なレビューを行いました。ありがとう。WCFが複雑すぎて、複雑さが自動的にマイナスになるわけではありません。あなたは将来それがあなたに提供する呼吸室に感謝するでしょう。マイクロソフトのツールでいつものように課題は、私たちがその未来を知らない、または制御できないことです。Microsoftがより統一されたシステムになり、数年間存続することを願っています。
構築する大きなシステムもあるので、その道のりがもっと明確ではないことが強調されます。これがすべて解決するまで、私はさらに2か月間延期する予定です。そして個人的に私はdatajsを応援しています（JayDataもチェックしてください）
単純に言えば、基本的なプロトコルから戻って、開発者/ユーザーの観点から見てください。Web APIは、WCFではなく、Microsoftの最初のクラスのHTTPベースのRest Frameworkです。つまり、Restの機能、仕様が不足している場合、それらはWeb APIパイプに追加され、必ずしもWCFに追加されるわけではありません。
はい、WCFでこれらを自分で実装できますが、文で言うように、これらを自分で実装する必要があります。
今日の例と同様に、Web APIの2要素認証の実装は、オープンソースプロジェクトとして開始された主に認証/承認のnugetパッケージであるOWINを使用して15分未満で完了します。
テクノロジースタックを使用する場合、Microsoftのファーストクラススタックを使用すると、大きな違いが生まれます。MSが公開したサンプルコードとプロジェクトをGithubに無数に配置して、自分のプロジェクトを簡単にコピーして開始することもできます。すべてのレベル、ドキュメント、コードサンプル、機能セット、サポート、ヘルパーAPIで違いがあります。
したがって、Restfull HTTPベースのアプリケーションを構築したい場合は、Web API（または移植性のためにASP.NET Core）を使用して、WCFから離れてください。プロトコルがHTTPではなく、実際にHTTPにできない場合は、WCFを使用します。
これは、この質問に対するTL; DRの回答です。
WCFは、データ通信と転送のためのWEB APIのドライバーへのスイスアーミーナイフです。WCFは、WEB APIが実行できるすべてのことを実行できますが、さらに必要な場合（TCPプロトコルを使用するなど）は、WCFが適しています。
ここに大きな比較があります。
WEB APIを使用する最大の理由の1つは、軽量であることです。これは、実装が簡単で、学習が容易で、保守が容易などです。HTTP上でRESTful Webサービスを必要とするWeb用に特別に設計されています。それはこれでうまくいきます。これで十分な場合は、おそらくWEB APIが適しています。
また、それはオープンソースです（もし気になれば）
WCFはWEB APIだけでなく、複数の転送プロトコル、複数の交換パターン（WEB APIはSignalRまたはWebソケットとの統合が必要）、SOAPサービスをWSDLで記述できる、追加のセキュリティ機能などをサポートします。この追加機能が必要な場合は、WCFを使用してください。
ODataは単に
クエリ可能で相互運用可能なRESTful APIを簡単かつ標準的な方法で作成および使用できるようにするオープンプロトコル。出典：http : //www.odata.org/
言い換えると、高レベルであり、RESTful HTTP要求の特定の文法を標準化しているだけです。これは、他のプロトコルと同じ利点を提供します。そして、少なくとも2013年以降、WCFとWEB APIの両方でODataの使用が許可されています。したがって、おそらくODataについて心配する価値はありません。