WCFデータサービス（OData）対ASP.NET Web API
RESTfulサービスとさまざまなクライアント（Silverlight、iOS、Windows Phone 7など）で構成される分散アプリケーションを設計しています。現在、サービス、WCF Data Services（OData）、またはASP.NET MVC 4で提供される新しいASP.NET Web APIを実装するために使用するテクノロジーを決定しています。
それぞれについてオンラインでいくつかのプレゼンテーションを見てきましたが、現在、主にURIに組み込まれているフィルタリングメカニズムとネイティブハイパーメディア機能のために、WCF Data Servicesに傾倒しています。私が見ることができる唯一の欠点は、Atom POXではなく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を簡単に置き換えることに満足しています。
Microsoftは、ASMXのシンプルさとWeb APIを使用したWCFのパワーとのバランスがとれたと確信しています。
現在、WebApiとWCF Data Servicesには他にも大きな違いがあり、誰も言及していないようです。 MSがこの2つを比較する良い記事を出してくれることを願っています。
私はしばらくODataとWebApiをフォローしています。私はいつもいくつかの大きな違いを見つけました。
まず、上司が「MSがWebApiを支援している」とはどういう意味かわかりません。ODataを支援していないということですか？ IMO、彼らは両方を支持しており、現在、最小限の重複があります。 Windows Azure Data MarketはODataを使用してデータを公開し、Azure Table StorageはODataを使用し、SharePoint 2010はそのデータに対するODataクエリを許可し、MSの他の製品（Excel PowerPivotなど）もサポートしています。リレーショナルデータに関しては、非常に強力なクエリフレームワークです。また、RESTfulであるため、あらゆる言語、フレームワーク、デバイスなどを統合できます。
OData + WCF Data Servicesで気に入っている点は次のとおりです。
OData + WCF Data Servicesは、Web経由でデータを照会する際に、クライアントアプリケーションがより「表現力豊か」になることを最終的に許可しました。以前は、UIがわずかに異なるものを必要とする場合は常に扱いにくく、一定の変更を必要とする厳格なWeb APIを構築するために、常にASMXまたはWCFを使用する必要がありました。クライアントアプリケーションは、パラメータを指定するだけで、返す条件を指定できます。または、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 Data Serviceに追加するだけで、LINQを使用してすぐにデータを照会でき、クライアントの「データコンテキスト」は、変更を追跡し、変更をサーバーにアトミックに「送信」できることを意味します。これは、RIA Services for Silverlightと非常によく似ています。 RIAサービスの代わりにWCF Data Servicesを使用していましたが、当時はDataAnnotationsまたはActionsをサポートしていませんでしたが、現在はサポートしています:)クライアントから。エンティティからすべてのプロパティを返したくない場合、これはパフォーマンスに役立ちます。基幹業務アプリを扱う場合は、クライアントに「データコンテキスト」を設定すると便利です。
したがって、WCF Data Servicesは、特にSQL ServerとEntity Frameworkを使用している場合、リレーションシップを持つデータがある場合に最適です。 RESTは非常に少ないコードでクエリ可能なデータ+アクション（操作、ワークフロー、バックグラウンドプロセスを呼び出すための呼び出し）を公開できます。WCFData Servicesが更新されました。新しいリリースが開始されました。 。すべての新機能をチェックしてください。
WCF Data Servicesの欠点は、HTTPスタック上で失う「コントロール」です。最大の欠陥は、コレクションを返すIQueryable<T>メソッドにありました。 RIAサービスおよびWebApiとは異なり、IQueryableメソッドでロジックを開発するための完全なアクセス権はありません。 RIAサービスおよびWebApiでは、IQueryable<T>を返す限り、任意のコードを記述できます。 WCF Data Servicesでは、Expression<Func<T,bool>>インターセプターメソッドを使用して "Where"ステートメントを追加するアクセス権のみを取得します。これは残念です。現在のアプリケーションではRIAサービスを使用しており、IQueryableロジックを制御する機能が本当に必要であることがわかります。私はこれで間違っていると思います
また、WCF Data ServicesはまだすべてのLINQオペレーターを完全にサポートしていません。ただし、まだWebApi以上のものをサポートしています。
WebApiはどうですか？
- Http要求/応答の制御が好き
- 簡単にフォローできます（MVCパターンを活用）。もっとツールが来ると確信しています。
WebApiは実際にはWCF Data Services/ODataのようなエンティティデータモデルではないため、現在（私の理解では）、クライアント（つまり、Silverlight、ASP.NETサーバー側コードなど）での「データコンテキスト」サポートはありません。です。 IQueryable/IEnumerableを使用してモデルオブジェクトのコレクションを公開できますが、「データコンテキスト」がないため、エンティティがクライアントに読み込まれると使用する主キー/外部キーの「ナビゲーションプロパティ」（つまりcustomer.Invoices）はありません。非同期に（または$ expandを使用した1回の呼び出しで）ロードし、変更を管理します。 RIAサービスやWCFデータサービスで行うような、クライアント上のエンティティデータモデルのコード生成された「表現」はありません。データを表すモデルをクライアントに持てない/持たない、と言っているわけではありませんが、データを手動で入力し、取得した「顧客」ごとにどの「請求書」を設定するかを管理していますウェブ。これは、特にAsyncのすべての処理が進行しているため、注意が必要です。どの呼び出しが最初に戻るかわかりません。これをここで説明するのは難しいかもしれませんが、RIA Servicesまたは WCF Data Services の「データコンテキスト」について読んでください。したがって、基幹業務アプリを扱うとき、これは私にとって大きな問題です。これは主に生産性と保守性に基づいています。データコンテキストなしでアプリを時代遅れに構築できます。特に、Silverlight、WPF、そして今ではWindows 8 Metroで、作業が簡単になります。リレーショナルエンティティを非同期にメモリにロードし、Two-Bindingを使用するのは本当に素晴らしいことです。
とはいえ、これはいつかWebApiがクライアントで「データコンテキスト」をサポートできることを意味しますか？できると思います。また、より多くのツールを使用すると、Visual Studioプロジェクトはデータベーススキーマ（またはEntity Framework）に基づいてすべてのCRUDメソッドを生成できます。
また、WCF Data ServicesまたはWebApiでの作業に関しては.NET Frameworksのみに言及していることは知っていますが、HTML/JSも主要なプレーヤーであることをよく知っています。私は、Silverlight UIやASP.NETサーバー側コードなどを扱うときに見つけた利点に言及したばかりです。HTML5/ JavaScriptでの「IndexedDB」の出現は、「データコンテキスト」とJavaScriptのLINQフレームワークも利用可能になり、JavaScriptからODataサービスへのクエリ機能がさらに簡単になります（ODataで現在DataJSを使用できます）。さらに、KnockoutJSを使用してMVVMとHTML/JSのバインドもサポートすることで、簡単になります:)
現在、使用するプラットフォームを調査しています。どちらを使用しても満足ですが、次のアプリケーションは主にアナリティクス（読み取り専用）であり、表現力豊かなRESTful Apiが欲しいという事実に基づいて、ODataに傾倒する傾向があります。 OData + WCF Data Servicesは、WebApiがコレクションに対する$ take、$ skip、$ filter、$ orderbyのみをサポートするため、それを提供してくれると思います。 Projections、Includes（$ expand）などはサポートしていません。「Updates/Deletes/Inserts」はあまりなく、データはかなりリレーショナルです。
他の人が議論に加わり、考えを述べてくれることを願っています。私はまだ決定しています、そして、他の意見を聞きたいです。どちらも素晴らしいフレームワークだと思います。必要に応じて両方を選択する必要があるのではないかと思います。クライアントからは、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おそらく開始するのに最適な場所です。
デバロンは、私がまだ見つけていないWCFとWeb Apiの最も有益なレビューを行いました。ありがとう。ここで、WCFが複雑すぎるという点までは、複雑さが自動的にネガティブになるわけではないと言います。将来的にそれがあなたに与える呼吸部屋に感謝するでしょう。マイクロソフトのツールの場合の課題は、その未来を私たちが知らない、または制御できないことです。マイクロソフトがより統一されたシステムになり、数年の間存続することを願っています。
また、構築するための大きなシステムもありますが、その道筋はそれほど明確ではないことを強調しています。これがすべて落ち着くまで、私はさらに数ヶ月先送りするつもりです。そして個人的に私はdatajsを応援しています（JayDataもチェックしてください）
もっとも簡単に言えば、このようにして、基礎となるプロトコルから離れ、開発者/ユーザーの観点からこれを見てください。 Web APIは、WCFではなく、Microsoftの最初のクラスのHTTPベースのRest Frameworkです。つまり、Restの機能、仕様が欠けていると、それらはWeb APIパイプに追加され、必ずしもWCFに追加されるわけではありません。
はい、WCFでこれらを自分で実装できますが、文で述べているように、これらを自分で実装する必要があります。
今日の例として、Web APIに2要素認証を実装する場合、OWINを使用して15分未満で完了します。OWINは、主にオープンソースプロジェクトとして開始された認証/承認nugetパッケージです。
テクノロジースタックを使用する場合、Microsoftのファーストクラススタックを使用すると大きな違いが生じます。 Githubには、数え切れないほどのMS発行のサンプルコードとプロジェクトがあり、自分のプロジェクトで簡単にコピーして開始することができます。あらゆるレベル、ドキュメント、コードサンプル、機能セット、サポート、名前を指定したヘルパーAPIで違いが生じます。
したがって、Restfull HTTPベースのアプリケーションを構築したい場合は、Web API（または移植性のためにASP.NET Core）を使用し、WCFから離れることをお勧めします。プロトコルがHTTPではなく、実際にHTTPにできない場合は、WCFを使用します。
これは、この質問に対するTL; DRの回答です。
WCFは、データ通信および転送用のWEB APIのドライバー用のスイスアーミーナイフです。WCFはWEB APIが実行できるすべてを実行できますが、さらに必要な場合（たとえばTCPプロトコル）を使用すると、WCFは行く方法。
これが 偉大な比較 です。
WEB API
WEB APIを使用する最大の理由は、軽量であることです。これは、実装が簡単で、学習しやすく、保守しやすいなどを意味します。HTTP用のRESTful Webサービスを必要とするWeb用に特別に設計されています。これを実行し、うまく実行します。これで十分な場合は、おそらくWeb APIが最適です。
また、それはオープンソースです（気になる場合）
WCF
WCFはWEB APIよりも多くのことを行います。複数の転送プロトコル、複数の交換パターンをサポートします（WEB APIはSignalRまたはWeb Socketsとの統合が必要です）、SOAPサービスはWSDLで記述できます。この追加機能が必要な場合は、WCFを使用してください。
OData
ODataは単純です
シンプルで標準的な方法で、クエリ可能で相互運用可能なRESTful APIを作成および使用できるようにするオープンプロトコル。ソース： http://www.odata.org/
言い換えると、高レベルでは、RESTful HTTPリクエストの特定の文法を標準化するだけです。どのプロトコルと同じ利点を提供します。そして少なくとも2013年現在、WCFとWEB APIの両方でODataの使用が許可されています。したがって、おそらくODataについて心配する価値はありません。