私は WCF RESTFull サービスの開発に不慣れで、新しい WCF Web API http://wcf.codeplex.com/と比較して webHttpBinding を使用することに関する有用な情報と経験のフィードバックを探しています。
私が探しているのは、webHttpBinding の欠点、したがって新しい Web API を使用する理由、特に新しい API が解決する問題について知ることです。両方を比較したり、webHttpBinding を使用する際の問題について話しているブログ記事をいくつか教えていただければ幸いです。前もって感謝します。
私が言う主な欠点は、webhttpbinding が HTTP 固有の問題の処理を困難にすることです。XML または JSON にシリアル化され、さまざまな形式で転送される可能性のあるオブジェクトを HTTP 経由で渡すだけであれば、うまく機能します。
HTTP は、XML および JSON の単純なトランスポート プロトコルをはるかに超えたものであり、豊富なセマンティクスを備えたアプリケーション層プロトコルです。Web API は、HTTP の豊富な機能をフルに活用する HTTP 経由のシステムを構築したい人を特にターゲットにしています。
Web API は、HTTP リソースがさまざまなクライアントのニーズに基づいて多数の表現を持つことができることを取り入れています。スペクトルの一方の端は、フォーム URL エンコードされた投稿と GET を使用してサービスと対話するだけのダム ブラウザである可能性があります。一方、もう一方の端は、Atom/OData またはハイパーメディア ベースのメディア タイプを使用するよりリッチなクライアントである可能性があります。
Web API は、仲介 Web サーバーをより有効に活用できるようにする、conneg、etags などの他の HTTP 固有の問題があることを受け入れます。
Web API はよりテストしやすいように設計されているため、よりテストしやすい方法で HTTP メッセージの操作やその他の問題に対処できます。
Web API には、より単純化された構成ストーリーがあります。
ここで理論的根拠の詳細を読むことができます: http://blogs.msdn.com/b/endpoint/archive/2010/11/01/wcf-web-apis-http-your-way.aspx
私にとって最も重要な違いは、プログラミング モデルの変更です。HTTP イディオム (GET、POST など) にバインドされた「操作」を公開する「サービス」を記述する必要はなくなりました。Web API を使用して、クライアントが対話できる「リソース」 (POCO) を作成します。
Web API は、さまざまなカスタム メディア タイプ (PNG 画像など) の処理に優れているようです。
最後に、Web API は自動テストにはるかに適しています。たとえば、静的コンテキスト クラスを使用して、応答コードなどの HTTP 概念にアクセスする必要がなくなりました。古いスタイルの new() 演算子を使用して、自動テストで簡単にインスタンス化できる POCO 要求および応答クラスを使用します。
Web API は現在プレビューにすぎず、その上にアプリケーションを構築することは危険であり、ライセンス契約によって禁止される可能性があるという Ladislav の意見に同意します (しかし、私はそれを確認していません)。
@serialseb の OpenRasta を検討しましたか? これは安定しており、RESTful サービスを構築するための非常に優れたプログラミング モデルを提供します。
Web API は、WCF での REST 開発の将来の可能性のようなものです。これは単なるプレビューであり、最終リリースの前に大幅に変更される可能性があります (おそらく .NET フレームワークの次のバージョンで)。したがって、実稼働 REST サービスを構築する場合は、webHttpBinding を使用する必要があります。
Web Api に関する入手可能な情報は、.NET Connected Framework チームのブログや、あなたが言及したサイトなどで見つけることができます。これは、現在の REST API の簡素化と拡張です。