サンプル2:RESTスタイルのWebサービス
SOAPベースのWebサービスは、厳密なXML定義を扱う関係上、前項のサンプル作成を見ても分かるとおり、クライアント実装においてもそれなりの手順を踏む必要があります。Visual Studioを使って参照クラスを自動生成すれば手順は簡略化できますが、Ajaxなどで簡単にアクセスするには敷居が高いと言えます。開発者としても、ブラウザで簡単に内容を確認できないのは歯痒いところです。
こうした問題点を受け、近年のWebサービスの潮流は、SOAPベースのものから、データを抽象化せず、直接XMLを扱うRESTスタイルのサービスへと向かいつつあります。
では、.NET Framework 3.5でサポートされたWebプログラミングモデルを使い、RESTスタイルのWebサービスを作成してみましょう。
変更の流れ
SOAPベースのWebサービスから、RESTスタイルのWebサービスに変更するには、以下の手順を踏みます。
- エンドポイントの設定変更
- HTTP GETのURIテンプレート指定
basicHttpBinding
から、WebプログラミングモデルのwebHttpBinding
に変更します。また、サービスビヘイビアとして、Webプログラミングモデルに必要なwebHttp
というビヘイビアを追加します。エンドポイントの設定変更
まずはABCの書き換えです。Microsoft Service Configuration Editorを起動し、WcfServiceTestプロジェクトのWeb.configファイルを開きましょう。
左上のConfigurationペインで[Advanced]-[Endpoint Behaviours]をクリックし、右上の[New Endpoint Behaviour Configuration]をクリックします。
[Add]ボタンを押し、ビヘイビア一覧ダイアログから[webHttp]を選択して[Add]ボタンを押します。
左上のConfigurationペインで[Services]-[WcfServiceTest.Service1]-[Endpoints]-[(Empty Name)]の下のアイテムをクリックします。ちなみに上のアイテムは前述のメタデータ交換用のエンドポイントです。
右ペインの[Behaviour Configuration]に先ほど作成したwebHttpBehavior
を、[Binding]にwebHttpBinding
を指定します。
これで、エンドポイントをSOAPベースからRESTスタイルのWebサービスに切り替えることができました。
HTTP GETのURIテンプレート指定
SOAPベースのWebサービスの場合、サービスのパラメータはPOSTで指定しますが、RESTスタイルのWebサービスの場合は、パラメータをHTTP GETリクエストのURIの中で指定します。従って、パラメータをURIでどのように表現するか(URIのテンプレート)を定義する必要があります。これはコントラクトと同様に属性として、ソースコード中に付加します。
次のように、公開するメソッドにWebGet
属性を追加し、UriTemplate
プロパティに引数名を{}に含める形でURIを記述します。
[OperationContract] [WebGet(UriTemplate = "Hello?name={name}")] string GetMessage(string name); [OperationContract] [WebGet(UriTemplate = "GetAddressBook/{id}")] AddressBookEntry GetAddressBookEntry(string id);
WebGet
属性のUriTemplate
プロパティで指定したURIは、そのサービスのAddressの後に付加されます。
従って、今回のAddressは
http://localhost/WcfTest/Service1.svc
ですので、その後にURIテンプレートを付加した
http://localhost/WcfTest/Service1.svc/Hello?name=doi
というアクセスは
IService1.GetMessage("doi")
という形式でメソッドを呼ぶことに対応します。
同様に
http://localhost/WcfTest/Service1.svc/GetAddressBookEntry/1
というアクセスは
IService1.GetAddressBookEntry("1")
という形式でメソッドを呼ぶことに対応します。
URIテンプレートにおいて、パスなどは自由に使用することができますので、それぞれの処理に意味のあるURIを割り当てることができます。今回は引数をクエリストリングやパスとして表現しました。
サンプル実行
では、再度IISへの発行を行い、実行してみましょう。
http://localhost/WcfTest/Service1.svc/Hello?name=doi
http://localhost/WcfTest/Service1.svc/GetAddressBookEntry/1
それぞれの結果が、直接XMLで表示されていることに注目してください。型名がルート要素となり、それ以下にフィールドが並んでいます。
こうしたシンプルなXMLであれば、クライアントでのパースも楽に行うことができるでしょう。
SOAPベースのWebサービスからRESTスタイルのWebサービスに書き換えるまで、ほんのわずかな手順しか掛からなかったことに注目してください。HTTP GETのURIテンプレートを記述する、という少しの手間以外は、ABCを書き換えるだけで切り替えを行うことができました。
サンプル3:JSONサポート
では、さらに対応形式を変えてみましょう。Ajaxで頻繁に使用されるJSON形式です。JSONはWebブラウザ上のJavaScriptで、文字列としてパースする必要がなく、直接扱うことのできるテキストベースのデータエンコード形式です。前述の通り、.NET Framework 3.5から、WCFでもJSONがサポートされるようになりました。
JSONはRESTスタイルのWebサービスと同様、WCFのWebプログラミングモデルでサポートされており、バインディングは共通のwebHttpBinding
を使用します。従って、ABCの変更は不要で、ごくごくわずかな設定の書き換えだけでJSONサポートを行うことができます。
WebGet属性の書き換え
JSONサポートに必要なのは、WebGet
属性のResponseFormat
プロパティを指定する、ただそれだけです。
次のように、「IService1.cs」内のサービス・コントラクトのWebGet
属性に、ResponseFormatとしてWebMessageFormat.Json
を指定します。
[OperationContract] [WebGet(UriTemplate = "/Hello?name={name}", ResponseFormat = WebMessageFormat.Json)] string GetMessage(string name); [OperationContract] [WebGet(UriTemplate = "/GetAddressBook/{id}", ResponseFormat = WebMessageFormat.Json)] AddressBookEntry GetAddressBookEntry(string id);
以上で書き換えは終了です。
JSONサポート確認
では、再度IISへの発行を行い、実行してみましょう。
それぞれ、次のような結果が返ってきます。
http://localhost/WcfTest/Service1.svc/Hello?name=doi
"Hello doi!"
http://localhost/WcfTest/Service1.svc/Hello?name=foo
"Hello foo!"
http://localhost/WcfTest/Service1.svc/GetAddressBookEntry/1
{"Address":"Tokyo","Id":1,"Name":"Doi"}
http://localhost/WcfTest/Service1.svc/GetAddressBookEntry/2
{"Address":"?","Id":0,"Name":"Anonymous"}
文字列を返すだけのGetMessage
ではよく分かりませんが、GetAddressBookEntry
の結果を見ると、フィールドと値が:や,で区切られた、JSON形式で正しく出力されていることが分かります。
切り替え所要時間は数十秒、といったところでしょうか。REST化以上にJSON化は簡単だったことが実感できたかと思います。
まとめ
WCFの概念と、Visual Studio 2008を使ったWebサービスの構築、RESTスタイルのWebサービス・JSONサポートについて、概観することができました。WCFの機能は非常に大きく、1つの記事ですべて説明することはできませんが、ここで基本的な概念を掴むことができましたので、他の通信方式や、さまざまなビヘイビアなどを扱う場合にも、MSDNのドキュメントを参照しながら理解を進めていけるでしょう。
実のところ、Visual Studio 2005+ExtensionsとVisual Studio 2008のWCFサポートは、特別な機能差はありません。これは、Visual Studio 2005+Extensionsの時点でMicrosoft Service Configuration Editorが組み込まれており、既に実装に十分な機能を提供していたためです。しかし、.NET Framework 3.5でWCFに加えられた機能は非常に強力で、これまでWCFを使うことのなかった、より多くの開発者が、RESTスタイルのWebサービスやJSONサポートなどの機能を使うため、WCFベースのWebサービス実装に取り組むことになります。そうした際に、.NET Framework 3.5とWCFを標準サポートしたVisual Studio 2008は、心強い味方となってくれることでしょう。
.NET Framework 3.0のWCFでは、通信方式を簡単に切り替えられる、共存できると言っても、現実的なユースケースが正直想像しづらかったのですが、.NET Framework 3.5のWCFでは、SOAPベースのWebサービス・RESTスタイルのWebサービス・JSON形式などを混在させながら同時に提供するなど、WCFがもともと持っていたポテンシャルを存分に発揮できるようになりました。今後さらに新しいデータの表現形式が出てきたとしても、WCFベースのサービスを構築しておけば、WCFでサポートされた時点ですぐに対応できます。あるいは新しいバインディングを開発すれば、WCFのバージョンアップを待つことなく、新しい形式に対応することもできます。Visual Studio 2008で正式にサポートされた強力な通信フレームワークであるWCFに、この機会にぜひ取り組んでみてください。
次回は、.NET Framework 3.0から導入されたワークフローフレームワークであるWFについて、Visual Studio 2008でどのように利用できるかを特集します。
参考資料
- WCF Webプログラミング モデル
- WCF(Windows Communication Foundation)チュートリアル 前編