ここ数年、私は多くの Web API の台頭を見てきました。サービスは、より正式なサービス コントラクト (SOAP や WS* など) ではなく、プレーンな HTTP を介して公開されます。Microsoft は "ASP.NET Web API" と呼ばれる新しいフレームワークを発表しました。これにより、幅広いクライアントに到達する HTTP サービスを簡単に構築できます。私が .net ファンなら、それは別の通信フレームワークです (asmx、wcf、ria、... の後)。今、幸せな建築家として働いている私は、テクノロジーについて決定を下さなければなりません。
Asp.net Web Api は本当に新しいアーキテクチャに適しているのでしょうか? Linq2Sql を思い出してください。「使い捨て」の API に投資したくありません。
WCF での WebBindings の使用はまだありますか?
この質問の問題は、スタック オーバーフローの質問であるという点で、基本的に主観的であることです。その結果、閉鎖されると確信していますが、とにかく2ペンス（実際には2ポンドのようです）を固執し、閉鎖された場合はそうします。
まず、Linq2Sql は「使い捨て」ではありません。まだそこにあり、なくなることはありません。それは開発されていません- それは完全に別の問題です。
とにかく - Asp.Net Web API は、Asp.Net MVC で作業する同じチームの多くの人々による REST Web サービス サポートの形式化であり、拡張性、パイプライン処理、分野横断的な懸念 (たとえば、認証、ロギング、検証) など。それを使用するかどうかは、RESTful Web サービスを開発するつもりであるかどうかにかかっています。あなたが.Net 4+を使用している場合、私の意見では、そうしないと気が狂うでしょう。
Web API の全体的なアーキテクチャは非常に優れており、あまり労力をかけずにそのほとんどを拡張できます。特に、彼らがコンテンツ ネゴシエーションを処理する方法は非常に優れており、たとえば、JSON 要求をサポートすることは簡単ですが、クライアントがContent-Type:application/jsonとAccepts:application/xml.
また、サーバー テクノロジとしては非常に高速です。部分的には完全に非同期であるため (スケーラビリティが向上します)、また、着信するリクエストと呼び出されるコードの間のスタックが非常に浅いためです。
それだけでなく、IIS と任意の .Net アプリケーションの両方でホストすることもできます。これにより、ホスティング オプションが増えるだけでなく、共通ネットワーク (つまり、非インターネット) 環境内のネットワーク内通信の候補にもなります。
ただし、SOAP または WS-HTTP サービスを作成する場合は、いいえ、Web API は適していません。WCF を使い続けることになります。
つまり、Asp.Net Web API は、プロトコルや Web アーキテクチャではなく、純粋に .Net 上で実行されるサーバーおよびクライアント テクノロジと考える必要があります。これにより、RESTful Web サービスを構築できます。MVC、WebForms (本当に必要な場合)、.ashx ハンドラー、または独自の HttpListener を作成することによっても構築できます。
どちらを選択するかは、完全にあなた次第です。
ASP.NET Web API は、WCF Web API の置き換えと呼ぶことができます。よりプラットフォーム指向のサービスをサポートします。