web-dev-qa-db-ja.com

ASP.NET MVCをWebサービスとして使用する

ASP.NET MVCプロジェクトをWebサービスとして使用した経験はありますか?

つまり、ビューなしでASP.NET MVCを使用しているため、他のアプリケーションはURLを使用してGETまたはPOST=コントローラーのアクションにアクセスできます。

誰かがそれを使用しましたか?もしそうなら、代わりにWebサービスプロジェクトを使用しないことの欠点はありますか?

よろしくお願いします!

15
Henry Aung

それは本当にあなたが書いているアプリケーションの種類に依存します。私は実際にLukLedの立場の逆を主張します。SOAPベースのサービスは、Windows認証や、TCPやMSMQなどの異なるプロトコルをサポートする場合、内部クライアントに適しています。

特定の「リソース」を中心に、よりWebスタイルのGETおよびPOSTを使用すると、 RESTアーキテクチャスタイル に入るようになります。この手法には、いくつかの明確な利点があります。

  • 特にJSONなどの軽量形式を使用する場合、応答は通常小さくなります。
  • リクエストとレスポンスが単純であるため、モバイル/ネイティブアプリケーションでの使用がはるかに簡単になります(たとえば、 TwitterのAPI を参照)。
  • 作成するサービスは、通常のWebページと同じようにAPIの他の部分にリンクできるため、自己記述的で発見可能なものにすることができます。

ここで特にトレードオフを理解するのに役立つ1つの記事は、Martin Fowlerの 「RESTの栄光に向けたステップ」 です。 。

よりRESTベースのサービスを構築する場合は、他の人が述べたように、MVC4に組み込まれている ASP.NET Web API の使用を検討してください。それは現在ベータ版ですが、Microsoftはそれについて十分に満足のいくライセンスを与えるためにそれを感じました。

UPDATE:

ASP.NETコア以降、ASP.NET Web APIはMVC 6プロジェクトに統合されました。 https://wildermuth.com/2016/05/10/Writing-API-Controllers-in-ASP-NET-MVC-6

8
Brandon Linton

単純なGETとPOST呼び出しを使用する場合は、MVCが最適です。ASP.NETMVC 4は、HTTPベースのAPIの作成をサポートします。これについては、こちらをご覧ください。 http://www.asp.net/web-api

Webサービスプロジェクトで作成されたWebサービスは、WSDLファイルを生成でき、(SOAPプロトコルを使用することにより)多くの異なる言語で簡単に読み取って使用できるため、使用が容易になります。)側では、WSは巨大なXML応答を作成できます。独自のフォーマットを使用した場合、それは何倍も小さくなる可能性があります。

Webサービスを世界中に広げたい場合は、SOAP=を許可すると、多くの開発者の生活が楽になります。SOAPは、プログラミングについては何も考えていません。内部で使用する場合は、速度と単純な要求と応答を優先して、MVCを使用できます。

8
LukLed

新しいASP.NET MVCには、Web Api Kitが含まれています。現在のバージョンでは引き続き使用できます。それには実際の欠点はありません

2
fenix2222