イントラネットサービスにWCFが使用される理由は何ですか？

Question

私が取り組んでいる新しいプロジェクトがあります。 プロジェクトの目的は、すべてのサービスコールを集中化し、他のサービスに単一のエントリポイントを提供することです。

現在、さまざまなソースから内部的にデータを取得するために開発者が呼び出すサービスは約5種類あります。

このプロジェクトでは、会社内の他の開発者がこれらの5つの異なるサービスをすべて単一のサービスから呼び出すことができる単一サービスを作成します。

私は、Web API（RESTfulな）またはWCF（SOAPベース）を使用してサービスを構築する必要があります私の質問は

のですか？

私はこのサービスを作成するための安らかなアプローチを私のマネージャーから提案されました。しかし、このサービスは社内で使用されているので、WCFはWSDLのために適切なアプローチであると信じています。これは、返されたデータを解析するクライアントではなく、プロキシクラスの作成とオブジェクトの使用です。

また、WCFはアクション駆動型で、Web APIはリソース駆動型です。

アクション駆動型モデルはいつ使用しますか？リソースドリブンはいつ使用しますか？

私の状況を把握して、どのアプローチを自分のプロジェクトに適用するかを決定するのに役立ちます。

これまで私がこれまで持っていたことはありますが、まだどちらかを使うように説得するには十分ではありません。

WCF

1. SOAPベースのサービス
2. 複数のトランスポート・プロトコル（等HTTP、TCP、UDP）
3. プロキシを作成するためのWSDL（タイプ安全なバインダークラス/オブジェクトを生成）
4. それクライアントがクラスライブラリのようにサービスエンドポイントを参照することができます。つまり、デスクトップクライアントのXMLまたはJSONを処理していません。あなたはクラス&オブジェクトで作業しています。
5. サービスはサービス

のWeb APIを文書化するために+

WCFExtrasを行うことができるどのような行動に焦点を当てたWeb API

内部/イントラネット

アクション駆動型モデルに比べてより多くのオーバーヘッドを持っています最初の（ベース

1. RESTfulサービス
2. HTTPクラス市民）メディアタイプ（XML、JSONの
3. ワイド品種）
4. 公開API（クライアントの多種多様）
軽量
5. ないWSDL（多くの場合、クライアントが自分でデータを解析して終了）

闊歩

を使用してオブジェクトに基づいて、エンドポイントではなく機能

クライアントの相互運用性

ASP.NETのWeb APIのヘルプページを公開し

リソース駆動型アーキテクチャ

UPDATE：

私の質問は、WCFは、イントラネットアプリケーションのために使用すべきである理由を理解することです。それは自動的にプロキシ・クラスを作成するWSDLとWeb APIであるため、返されたXMLまたはJSONを解析するためにクライアント側でより多くの作業を行う必要がありますか？

Answer 1

考慮すべき1つの要素は、既存のサービスコードが既存のサービスに「組み込まれている」かどうかです。私が新しいサービスを作成した数年の間、すべてのコードはWCFサービスアプリケーションの一部でした。それは好都合に思えましたが、それは近視眼的でした。

アプリケーションコンポーネントがWCFサービスまたはWeb APIのいずれかによって公開される独自のライブラリに組み込まれている方がずっと優れています。それがそのように構築されている場合は、どちらか一方を行う方が簡単で、もう一方を行う方が簡単です。

私は、1）すべてのクライアントがそれを消費するのが容易であり、2）誰もが最近Web APIに焦点を当てているようで、経験を積み重ねるのに適しているからです。

内部で使用されているAPIの場合、私にはWCFサービスと同じ利点がいくつかあります。

• 「サービス」はAPIとは別のライブラリです。これは単なるクラスライブラリで、私はAPIとは別にテストできます。
• APIとそのモデルのインターフェイスを別のライブラリに作成します
• APIをテストするために独自のクライアントコードを作成する必要があるため、サービスインターフェイスを実装する再利用可能なHTTPクライアントを作成します。他の開発者はそれを使用する必要はありませんが、必要な場合は、そのインタフェースと既存のクライアントを追加できます。こうすることで、独自のクライアントコードを作成してテストするのではなく、既に実行されテストされていることがあります。また、依存関係注入に便利な別個のインタフェースと実装も用意されています。
• 多すぎるかもしれませんが、私のAPIは同じサービスインターフェイスを実装しています。こうすることで、開発プロセス中にインターフェースを変更した場合（公開されたインターフェースの変更を破ることについて話すのではなく）、API、クライアントなどを更新する必要がある場所を確認するのは本当に簡単です。

これは、内部クライアントとの連携欠点は、おそらくRESTful APIを開発するためのベストプラクティスとは「非接触」だということです。

IMO重要なのは、ロジックとAPIまたはWCF間の機能分離です。一方的にAPIを構築して別のことをしたい場合は、コードのより重要な部分を書き直したり再テストすることなく、その目的に集中することができます。