RESTful サービスとさまざまなクライアント (Silverlight、iOS、Windows Phone 7 など) で構成される分散アプリケーションを設計しています。現在、WCF Data Services (OData) か、ASP.NET MVC 4 で登場する新しい ASP.NET Web API のどちらのテクノロジをサービスの実装に使用するかを決定しています。
私はそれぞれについていくつかのプレゼンテーションをオンラインで見てきましたが、現在は主に URI に組み込まれているフィルタリング メカニズムとネイティブのハイパーメディア機能のために、WCF Data Services に傾倒しています。私が見ることができる唯一の欠点は、POX とは対照的に、Atom Pub 仕様の冗長性です。
決定を下す前に、これら 2 つのテクノロジについて知っておくべきことはありますか? WCF Data Services ではなく ASP.NET Web API を選択する理由は何ですか?
現在、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 経由でデータをクエリするときに、より「表現力豊か」になります。以前は、常に ASMX または WCF を使用して厳格な Web API を構築する必要がありましたが、これは扱いにくく、UI が少し異なるものを必要とするたびに常に変更を加える必要がありました。クライアント アプリケーションは、返す基準を指定するパラメータのみを指定できました。または、私が行ったようにLINQ式を「シリアル化」し、それらをパラメーターとして渡しExpressions<Func<T,bool>>、サーバーに再水和します。そのまともな。作業は完了しましたが、クライアントで LINQ を使用し、REST を使用して Web 経由で変換したいと考えています。これはまさに OData が許可するものであり、ソリューションの独自の「ハック」を使用したくありません。
これは、DB 接続文字列を必要とせずに「TRANSACT SQL」を公開するようなものです。URL を指定するだけで、おっと! クエリを開始します。もちろん、WebApi と WCF Data Services の両方が認証/承認をサポートしているため、アクセスを制御したり、ロールやその他のデータ構成に基づいて追加の "Where" ステートメントを追加したりできます。これは、SQL ではなく Web Api レイヤーで行いたいと思います (ビューやストアド プロシージャの構築など)。アプリケーションがクエリ自体を作成できるようになったので、アドホックおよび BI レポート ツールが OData を活用し始め、ユーザーが独自の結果を定義できるようになります。最小限の制御しかできない静的レポートに依存しない。
Silverlight、Windows 8 Metro、または ASP.NET (MVC、WebForms など) で開発する場合、Visual Studio の「サービス リファレンス」を WCF データ サービスに追加するだけで、すぐに LINQ を使用してデータのクエリを開始できます。クライアントの「データ コンテキスト」。これは、変更を追跡し、変更を原子的にサーバーに「送信」できることを意味します。これは、Silverlight の RIA サービスと非常によく似ています。RIA サービスの代わりに WCF Data Services を使用していたでしょうが、当時は DataAnnotations や Actions をサポートしていませんでしたが、現在はサポートしています :) WCF Data Services には、RIA サービスよりも別の利点があります。クライアントから。これは、エンティティからすべてのプロパティを返したくない場合に、パフォーマンスに役立ちます。「データコンテキスト」を持つ
そのため、特に SQL Server と Entity Framework を使用している場合、リレーションシップを持つデータがある場合、WCF Data Services は優れています。非常に少ないコードで REST を介してクエリ可能なデータ + アクション (オペレーションを呼び出すための呼び出し、つまりワークフロー、バックグラウンド プロセス) をすぐに公開できます。WCF Data Services が更新されました。新しいリリースが開始されました。すべての新機能をチェックしてください。
WCF Data Services の欠点は、HTTP スタックに対する "制御" が失われることです。最大の欠陥は、IQueryable<T>コレクションを返すメソッドにあることがわかりました。RIA サービスや WebApi とは異なり、IQueryable メソッドでロジックを開発するための完全なアクセス権はありません。RIA Services と WebApi では、 を返す限り、任意のコードを記述できますIQueryable<T>。Expression<Func<T,bool>>WCF Data Services では、インターセプター メソッドを使用して "Where" ステートメントを追加するためのアクセスのみを取得します。これはがっかりしました。現在のアプリケーションは RIA サービスを使用しており、IQueryable ロジックを制御する機能が本当に必要であることがわかりました。私はこれについて間違っているといいのですが、何かが足りないだけです
また、WCF Data Services はまだすべての LINQ オペレーターを完全にサポートしていません。ただし、WebApi 以外もサポートしています。
WebApiはどうですか???
WebApi は実際には WCF Data Services/OData のようなエンティティ データ モデルに関するものではないため、現時点では (私の理解では)、クライアント (つまり、Silverlight、ASP.NET サーバー側コードなど) での「データ コンテキスト」のサポートはありません。は。IQueryable/IEnumerable を使用してモデル オブジェクトのコレクションを公開できますが、「データ コンテキスト」がないため、エンティティがクライアントにロードされた後に使用するプライマリ キー/外部キー「ナビゲーション プロパティ」(つまり、customer.Invoices) はありません。それらを非同期に (または $expand を使用した 1 回の呼び出しで) ロードし、変更を管理します。RIA Services や WCF Data Services の場合のように、コードで生成された Entity Data Model の "表現" はクライアントにはありません。私は、あなたのデータを表すモデルをクライアントに持つことができない、または持たないと言っているのではありません。ただし、手動でデータを入力し、Web 経由で取得した各「顧客」にどの「請求書」を設定するかを管理しています。これは、特にすべての非同期処理が行われている場合、注意が必要です。どのコールが最初に戻ってくるかわかりません。ここで説明するのは難しいかもしれませんが、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 サーバーサイド コードなどを扱うときに見つけた利点について言及したところです。HTML5/JavaScript で「データ コンテキスト」とJavaScript の LINQ フレームワークも利用可能になる可能性があり、JavaScript から OData サービスのクエリを実行する機能がさらに簡単になります (現在、OData で DataJS を使用できます)。さらに、KnockoutJS を使用して MVVM と Binding を HTML/JS でもサポートすると、簡単になります :)
現在、どのプラットフォームを使用するかを調査中です。どちらを使用しても問題ありませんが、次のアプリケーションは主に分析 (読み取り専用) に関するものであり、表現力豊かな RESTful Api が必要であるという事実に基づいて、OData に傾倒する傾向があります。OData + WCF Data Services は、WebApi がコレクションに対して $take、$skip、$filter、$orderby のみをサポートしているため、それを提供してくれると思います。プロジェクション、インクルード ($expand) などはサポートしていません。「更新/削除/挿入」はあまりなく、データはかなりリレーショナルです。
他の人が議論に参加して、考えを述べてくれることを願っています。まだ検討中ですので、他の方のご意見もお待ちしております。どちらも素晴らしいフレームワークだと思います。どちらかを選ばなければならないのだろうか、必要に応じて両方を使用してみませんか。クライアントからは、とにかく REST 呼び出しを構築することがすべてです。ちょっとした考え ：）
これは主観的な質問なので、主観的な回答を以下に示します。IMO、WCF は単純な RESTful サービスに対してオーバーヘッドが大きすぎます。一方、Web API は RESTful サービス専用に設計されています。
私はこれについて Dave Ward に同意します。詳細については、彼のブログをご覧ください。
私は長い間、WebForms プロジェクトで ASMX から WCF に移行するというプレッシャーに抵抗してきました。なぜなら、WCF の複雑さを受け入れることは、主に柔軟性の低い JSON シリアライゼーションで報われるだけだったからです。対照的に、私は自分のプロジェクトのいくつかを ASMX から Web API に変換し始めており、Web API が ASMX を簡単に置き換えることができることに満足しています。
Microsoft は最終的に、ASMX のシンプルさと Web API を使用した WCF の能力との間で適切なバランスを見つけたと思います。
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 ビジネスを完全にスキップして、コレクションを直接クエリできます。
要するに、ASP.Net MVC プロジェクトに .svc ファイルを配置することを妨げるものは何もないということです。それは二者択一の命題ではありません。サーバーにデータ サービスを追加すると、多くのコントローラーを作成する必要がなくなりますが、必要に応じて追加のコントローラーを作成する必要がなくなります。
言い換えると ：
データ モデル (EDM など) をすばやく公開することを検討していて、多くのコードやビジネス ロジックを必要としない場合は、WCF Data Services を使用すると、それが非常に簡単になるため、出発点として適しています。
API を構築していて、単に OData クエリ構文または書式設定を使用して一部のリソース (およびロジック) を公開したい場合は、おそらくASP.NET Web APIが最適な出発点です。
Devaron は、私がまだ見つけていない WCF と Web Api の最も有益なレビューを提供しました。ありがとう。WCF が複雑すぎるというところまで来ましたが、複雑さは自動的にマイナスになるわけではありません。将来、あなたに与えられる息抜きの部屋に感謝するでしょう。Microsoft ツールの課題は常にそうであるように、その未来を知ることも制御することもできないということです。Microsoft が最終的により統一されたシステムになり、それが数年間存続することを期待しましょう。
また、大きなシステムを構築する必要があり、その道筋がはっきりしないことにストレスを感じています。これがすべて落ち着くまで、あと数か月間延期する予定です。個人的には datajs を応援しています (JayData もチェックしてください)
これは、この質問に対する TL;DR の回答です。
WCF は、データ通信と転送のための WEB API のねじ回しに対するスイス アーミー ナイフです。WCF は、WEB API が実行できるすべてのことを行うことができますが、さらに必要な場合 (たとえば、TCP プロトコルを使用する場合) は、WCF を使用することをお勧めします。
ここに素晴らしい比較があります。
WEB API を使用する最大の理由は、軽量であることです。これは、実装が簡単で、習得が容易で、保守が容易であることを意味します。HTTP を介した RESTful Web サービスを必要とする Web 向けに特別に設計されています。それはこれを行い、それはうまくいきます。これだけあれば、おそらく WEB API が最適です。
また、それはオープンソースです（気にするなら）
WCF は WEB API よりも多くのことを行います。複数の転送プロトコル、複数の交換パターン (WEB API は SignalR または Web Sockets との統合が必要) をサポートし、SOAP サービスを WSDL で記述でき、追加のセキュリティ機能を備えています。この追加機能が必要な場合は、WCF を使用してください。
OData は単に
シンプルで標準的な方法で、クエリ可能で相互運用可能な RESTful API の作成と使用を可能にするオープン プロトコル。ソース: http://www.odata.org/
つまり、大まかに言うと、RESTful HTTP リクエストの特定の文法を標準化するだけです。これは、どのプロトコルと同じ利点を提供します。少なくとも 2013 年現在、WCF と WEB API の両方で OData を使用できます。したがって、OData について心配する価値はおそらくありません。