Web APIは、httpプロトコルをよりネイティブに活用します。Odataは、多くの大手企業が採用しているオープンスタンダードです。私は、Odataをいじくり回し、最近Web APIを発見し、いくつかの調査を行った経験からしか話せません。
ODataは実際の標準なので、クールです。データベースを簡単に作成し、HTTPで公開できます。これは、設定なしでテーブル構造をトラバースできることを意味します(大まかに言って)。いくつかの軽いLINQを含むことができるURLを介してクエリを実行することもできます。
/products/orders/[put some linq-ish query here]
これは間違いなく良いか悪いです。認証は標準であり、構築されています。
Web APIは、私の観点からはより興味深いものです。HTTP機能(エラーメッセージなど)を利用し、真のRESTfulリクエストに対してもう少し「ネイティブ」です。私は実際にあまり遊んでいませんでした。しかし、私は読み返し、MVCとWeb APIがいつか「結婚」するかもしれないという「聞いた」ことがあります。
ODataで遊んでいたとき、ストアドプロシージャを作成し、エンティティサーフェスにマッピングし、強い戻り値の型を構成してから、URLリクエストとBANGにフックしました。それはかなり簡単で、必要なものを正確に入手できました。
結論として、
私はWCF APIを詳細に扱う機会はありませんでしたが、RESTへのより純粋なアプローチであるため、クライアント開発に進む方法だと思います。多かれ少なかれ「ストレート」な往復呼び出しを行い、「モデルの表示」を取得する場合、よりネイティブなインタラクションが提供されます。
一方。クライアントとのやり取りに基づいてデータに対して複雑な(っぽい)クエリを作成し、クエリロジックを「構築」してパラメータとして渡したい場合、Odataを使用できます。
私がそれを見る方法は、構造形式(テーブル/関係構造を意味する)でデータを公開し、クライアントから直接クエリする必要がある場合です、Odataは最適に動作します。また、「その他」が(適切な認証などを使用して)データにアクセスできるようにするのにも適しているため、ODataプロトコルに準拠しています。
URL(/ products / orders / 22を指定し、「隠された」マネージコードとデータ構造から複雑な「結果セット」を作成するRESTfulリクエストが必要で、HTTP応答メッセージも役立つ場合があります。 Web APIがおそらく最善の策でしょう。
繰り返しになりますが、これはすべて研究とおもちゃです。実稼働/本格的なアプリシナリオのいずれにも実装していません。彼らは両方とも長所と短所を持っていると思うし、間違いなくいくつかの重複がある