基本的なhttpbindingを備えたWCF APIが既にあります。一部の呼び出しでは、応答と要求の両方に複雑なオブジェクトがあります。
APIにRESTful機能を追加する必要があります。最初にwebHttpエンドポイントを追加しようとしましたが、
At most one body parameter can be serialized without wrapper elements
私がそれをラップした場合、私が必要とするほど純粋ではありませんでした。
私は this と this (「ASP.NET Web APIは.NETでRESTfulサービスを構築するための新しい方法である」と述べています)を読む必要がありました。
だから私の質問は、2つのAPI(2つの異なるプロジェクト)を作成する必要があるかどうかです。 1つはSOAP for WCFで、もう1つはRESTfulでASP.NET Web APIを使用しますか?このアプローチでアーキテクチャ的に話すと何か問題がありますか?
私はこれを見つけるまで同じ質問をしていました WCFとASP.NET Web API MSDNの比較ページ(以下に私自身の重点を置きます):
WCFを使用して、さまざまなトランスポートを介してアクセスできる信頼性の高い安全なWebサービスを作成します。 ASP.NET Web APIを使用して、さまざまなクライアントからアクセスできるHTTPベースのサービスを作成します。新しいRESTスタイルのサービスを作成および設計する場合は、ASP.NET Web APIを使用してください。 WCFはRESTスタイルのサービスを作成するためのいくつかのサポートを提供しますが、ASP.NET Web APIでのRESTのサポートはより完全であり、すべての将来のREST ASP.NET Web APIで機能が向上します。既存のWCFサービスがあり、追加のRESTを公開する場合エンドポイントには、WCFとWebHttpBindingを使用します。
IMO、2つのAPI(2つのプロジェクト)を使用することは良いアプローチではありません。保守の問題が発生し、サービスのコンシューマー/クライアントを混乱させたりトラブルに巻き込んだりする可能性があります。
プロジェクトの要件とクライアントのニーズによって異なります。 SOAPが必須である場合は、@ Smokefootの回答に合わせて、WCFを使用してSOAPおよびRESTエンドポイントを公開します。クライアントはSOAP=を使用することを望んでおり、RESTを望んでおり、WCFバージョン(Webサービスv1)での開発を停止し、ASP.NET Web API(Webサービスv2)に移行します)
これはあなたの質問に対する直接の答えではありませんが、あなたが探求するための代替手段です。
私の他の答えに加えて、 ServiceStack と呼ばれる別の.NET Webサービスフレームワークをチェックアウトすることもできます。それについていくつかの良い点:
servicestack
tag を使用して、プロジェクトの作成者であるDemis Bellot(別名 mythz )による優れたサポート。ServiceStackとASP.NET Web APIを比較した注目すべき言及:
ServiceStackについて詳しく知りたい場合は、必ず 公式サイト をチェックしてください。コードとドキュメントは GitHub にあり、プレゼンテーションは slideshare にあります。 =。
新しいASP.NET MVCに含まれている新しいWeb APIは、一部のAJAX機能を有効にするために、ページに休息サービスを追加するのに適しています。小さなAPIか、それは残ります。
RESTおよびSOAPをより大きなAPIとして実装するとき、私は常にWCFアプリケーションを使用することを好みます。すべてのWebサービスが中央プロジェクトに配置されています。