ASP.Net Web APIとWCFのどちらをプロジェクトで選択するか
WCFとASP.Net Web APIの違いについて、これまでにWebで多くの記事を読みました。残念ながら、何が私の目的に役立つかについて明確なアイデアを思い付くことができませんでした。私が読んだ記事のほとんどは、2つのWebサービスの設計の観点からハイライトされています。しかし、私は自分のプロジェクトに何が最もうまく機能するのか、そしてなぜですか？これが私のプロジェクトの簡単な説明です。
2つのサーバー間に通信チャネルを作成する必要があります（どちらもC＃で記述されています）。サーバーはメッセージ（特定のタイプのコマンド）を使用して通信します。メッセージは確認応答のみの場合もあれば、計算を行うための指示が含まれる場合もあります。たとえば、1つのメッセージが何かを描画したり、SMSなどを送信したりすることができます。また、必ずしもメッセージにデータベーストランザクションが含まれるとは限りません。ただし、メッセージは大きなテキストファイルをペイロードとして送信する場合があります（約1 -5 MB maxm）。WCFが確実にこれを実行すると確信していますが、ASP.net Web APIでも同じことができます。これまでのところ、ASP.Net Web APIで見たすべての例は、ある種のDBストア（GET、PUT、DELETE）を操作するRESTfulサービスですが、私の場合は、サービスポイントを公開する必要があります。
計算の値を返す、メッセージの送信と確認などの処理を行う。
DBストアを操作するだけではありません。
それで、そうするための最良かつ最も簡単な方法は何でしょうか？ ASP.Net Web APIを使用してこれを実現する簡単な例は見つけられなかったことに言及する必要があります。
あなたが尋ねた質問は過度に広範であるか、主に意見に基づいており、あなたが尋ねたことの例を示すのは難しいです。
重要なポイント：
- まず、さまざまなプラットフォームで使用されるサービスを作成する場合は、WCFを使用します。
- 次に、外部リソースを使用するインターネットサービスを作成する場合は、Web APIを使用します。
- 低帯域幅のデバイスまたはモバイルデバイスがクライアントにアクセスするためのサービスを作成する場合は、Web APIが最適です。HTTP要求/応答は、ヘッダーが含まれているため、SOAP 、ボディなどが複雑になります。
いくつかの原則を完全に理解するまで、数分かけて以下の記事を読んでください。
元のソースは、 ここ 、 ここ および ここ で見つかります。
WCFまたはWEB APIのどちらを選択するか：
- 一方向メッセージング、メッセージキュー、二重通信などの特別なシナリオをサポートするサービスを作成する場合は、WCFを選択します。
- TCP、名前付きパイプ、または場合によってはUDP（WCF 4.5の場合）などの高速トランスポートチャネルを使用できるサービスを作成する場合はWCFを選択し、他のすべてのトランスポートチャネルが使用できない場合はHTTPもサポートする必要があります。
- HTTPのすべての機能（URI、要求/応答ヘッダー、キャッシング、バージョン管理、さまざまなコンテンツ形式など）を使用できるHTTPを介してリソース指向のサービスを作成する場合は、Web APIを選択します。
- ブラウザ、モバイル、iPhone、タブレットなどの幅広いクライアントにサービスを公開する場合は、Web APIを選択します。
Web APIを選択する理由
- Web APIには、WCF RESTサービスのような面倒で大規模な構成はありません。
- これは非常にシンプルで、Web APIを使用してサービスを作成します。 WCF RESTと同様に、サービスの作成は少し困難です（構成を明確に理解する必要があります）。
- Web APIはHTTPとHTTPSのみに基づいており、RESTフルな方法で簡単に定義、公開、使用できます。
- Web APIは軽量のアーキテクチャであり、スマートフォンのように帯域幅が制限されているデバイスに適しています。
私の意見：
- 最も簡単な方法-Web API（これの例がないため）
- 最も難しい方法は（構成）-WCF（例があるため、WCFを使用することをお勧めします）
これがあなたに何を選ぶべきかについての明確な考えを与えてくれることを願っています...
まず最初に、RESTfulはWebサービスに適用できるステートレスで統一されたインターフェース標準です。それは自動的である必要はなく、DBによってバックアップされたプレーンな古いCRUDサービスのみです。
現実の世界では、すべてのWeb REST APIが標準を完全に尊重しているとは言えません。実際、ほとんどの場合、特にステートレスな部分は無視されます。
メッセージベースのAPIの場合、特に双方向でイベントベースの場合は、websocketを使用して、REST APIを使用して、統一されたステートレスなWebインターフェイスを公開し、それらを作成する方法を検討できます。 ASP.NET WebApi でwebsocketを使用します。新しいASP.NET Coreであっても、チュートリアルはたくさんあります。
「サービス間」の相互作用の部分は、通常のWebブラウザー<=> Webサービスと同じで、クライアントにJSの代わりにC＃コードを使用しているだけです。
SOAPを使用するWCFは、今日のWeb標準を考えると移植性が低いため、お勧めできません。たとえば、別のASP.NETサービスの代わりにブラウザークライアントを使用したい場合は、サポートを処理するためにクライアント側で追加のコードを実行します。
WCF websockets を使用して、WCF SOAPのほとんどすべての利点を提供できます。
tl; dr：
- RESTfulとWebsocketを混在させることができますが、実際にはフルになるRESTまたは完全なWebsocketよりも優れています。
- WebSocketよりもSOAP=を使用するのは個人的な好みですが、後で何をしたいかを考慮すると、潜在的な技術的負債が伴います
- サービス間のメッセージAPIは、サービスとブラウザ間のメッセージAPIと同じです
WebAPIはRESTful Webサービスに適しているだけではありません。リクエストをWebAPIコントローラーに簡単に送信して、計算、メッセージの送信、CRMとのやり取り、DBとのやり取りなど、さまざまな方法で処理できます。
WCFは、SOAP=ベースのWebサービスを管理するために作成され、さらに複雑さをもたらします。TCP、MIMEを処理します...
HTTPリクエストを処理する必要があるだけの場合、最も簡単な方法はWebAPIを使用することです。
WCFがRestfulサービスとして機能するように作成されていないため、Web APIがRESTfulサービス用である場合、Web APIが推奨されます。