WCFとSOAP・REST
WCF勉強中につき、メモ書きです。
『インサイドWindows Communication Foundation』を読みながら、関連を調べてという形で進めてます。
『インサイドWindows Communication Foundation』によれば、WCFは当初SOAP/WS-*を前提としている部分が大きかった様子。JSONなどの台頭自体はWCF開発チームにとって予想外だったのでは？という記載があった。JSONというか、RESTアーキテクチャスタイル。
WCFはSOAP, REST, POXをサポートしています。ただし、現在のWCF APIのほとんどは、SOAPメッセージ構造にのみ対応しています。
将来的には、JSONなどのほかのメッセージング構造にも対応するように拡張される予定です。
『インサイドWindows Communication Foundation/p.28』
※POXは「Plain Old XML」の略。SOAPのWSDLとの対比で利用される。
POX メッセージでは重要なプロトコル情報の搬送に SOAP ヘッダーを使用しないため、POX クライアントおよびサービスでは、メッセージの送受信に使用される、基になる HTTP 要求の情報を操作する必要が生じる場合がよく起こります。
『POX アプリケーションとの相互運用性 http://msdn.microsoft.com/ja-jp/library/aa738456.aspx』
その主な理由は 2 つあります。1 つは、REST には、多くの場合に RPC テクノロジより優れている重要な機能や利点があるということです。もう 1 つは、マイクロソフトが固有の実装の多くを SOAP などの RPC テクノロジから REST に移行する方向に向かっているということです。したがって、REST を使用してシステムを構築することに納得できず、その気にならない場合でも、マイクロソフトをはじめとするベンダが多くのフレームワークやテクノロジを REST に移行するようになると、REST の操作方法を習得せざるを得ません。
『REST および WCF サービスの概要 http://msdn.microsoft.com/ja-jp/magazine/dd315413.aspx 』
「SOAPはRPCだ」という言及がある。『Webを支える技術』でも、「SOAPはRPCをHTTP上で走らせるための技術だ』といった旨の言及があったことを見るに、この感覚は共通認識としてある様子。
RPC/分散オブジェクトグループの動きの中で最も基本的なプロトコルはSOAPです。SOAPは、HTTPをアプリケーションプロトコルではなくトランスポートプロトコルとして扱い、HTTPの上で独自のメッセージを転送します。SOAPはMicrosoftがW3Cに提案し、IBMやそのほかのベンダーを巻き込んで標準化が始まりました。
『Webを支える技術/p.021』
そういえば『インサイドWindows Communication Foundation』の中で、TCP・HTTP・名前つきパイプをまとめてトランスポート層みたいな言及があって「？」って思ったのだった。本読み進めるとき、少し気をつけてみておこう。
あと、MS自体がSOAPからRESTに向かってるという言及が気になる。
プログラミング モデルとインフラストラクチャの構築が必要な部分は、.NET Framework 3.5 の System.ServiceModel.Web アセンブリで WCF に追加されました。.NET Framework 3.5 SP1 では、いくつかの細かい点も改善されています。
『REST および WCF サービスの概要 http://msdn.microsoft.com/ja-jp/magazine/dd315413.aspx 』
System.ServiceModel.Web名前空間は、REST用らしい。そしてWebGetAttribute と WebInvokeAttributeが要、とも。
ルーティングの違い
メッセージのルーティングが、SOAPとRESTで異なる。
既定のメッセージルーティング(=ディスパッチ)はアクション概念に基づいており、SOAP仕様のActionヘッダを既定で利用するため、SOAPと密結合している。
RESTインフラストラクチャ利用の場合、これがURIおよびHTTP動詞に基づくルーティングに置き換えられる。(→ WebHttpDispatchOperationSelector )
WebGetAttribute は、メソッドが HTTP GET 要求に応答する必要があることをディスパッチャに通知します。WebInvokeAttribute は既定で HTTP POST にマップされますが、WebInvokeAttribute.Method プロパティを設定して、他の HTTP 動詞 (PUT および DELETE の 2 つが最も一般的) をサポートすることができます。既定では、URI は、エンドポイントのベース URI に追加されたメソッドの名前によって指定されます。
メソッド名は動詞を表しているので、この処理は RESTful とは言えません。URI として公開するには、名詞が適しています。そのため、WCF の REST プログラミング モデルでは、WebGetAttribute または WebInvokeAttribute の UriTemplate プロパティで設定可能なテンプレートを使用して、各メソッドの URI をカスタマイズできます。
『REST および WCF サービスの概要 http://msdn.microsoft.com/ja-jp/magazine/dd315413.aspx 』
そしてメソッドとURL・HTTP動詞のマッピングにWebGetAttribute・WebInvokeAttributeが用いられる。
More On REST
SOAP、REST、およびその他
http://msdn.microsoft.com/ja-jp/magazine/dd942839.aspx#MtViewDropDownText
simple != easy
I often say that REST is simple, but simple doesn't always mean easy. SOAP is easy (because of WSDL), but easy doesn't always mean simple.
『SOAP、REST、およびその他 http://msdn.microsoft.com/ja-jp/magazine/dd942839.aspx#MtViewDropDownText 』
hope that after you read this column, you'll think that the answer to "Which is better, REST or SOAP?" is "It depends."
当エントリは、「RESTもSOAPも一長一短」という形で締められている。
