ADO.NET Data Service:RESTfulな実装について4

  • Article

こんにちは、こだかです。

今回はRESTfulな世界とADO.NET Data Serviceを中心に、これまで触れていなかった特徴を含めてお話したいと思います。

まず、ステートレスに通信を行うと言う特徴です。
これは、HTTPリクエスト1つ1つが完全に分離されていて、サーバーに対するリクエストには常に必要な情報がすべて含まれていることを指します。
これに違反している例は・・・数多くあります。例えばASP.NETで使用するSessionがそうです。
Sessionはサーバーのメモリーや指定したDBに永続化されたクライアントの情報なのですが、これを使用すれば、別のページやタイミングでクライアントとサーバーのやり取りを引き継ぐことができるわけです。

では、何が問題なのか？
例えば、ブラウザの「進む」「戻る」ボタン、別クライアント環境での動作保障がない等が考えられます。またブックマークが難しい点もそうですね。
さらに典型的な例では、クッキーの使用自体がステートレスではないとも言えます。

ADO.NET Data ServiceはRESTfulな実装になりますので、このステートレスの原則を守っています。
そうすると、副次的なメリットも発生することがわかります。例えばスケーラビリティです。
Sessionのようにサーバーのメモリを使用しない点もそうですし、極端な話、リクエストを出すサーバーが、例えば1回目と2回目で異なったとしても、ステートレスですから、同じリソースを取得することができる可能性もあるわけです。
（当然、リソースはデータベースに繋がりますので、同じデータストアである必要はありますが…）

こうようなステートを使用しない特徴を考えるとき、当然ながら疑問も湧いてくると思います。例えば、認証系やトランザクションです。
通常RESTfulで考える場合、現状はWeb⇒HTTPですから、Basic認証やダイジェスト認証はもちろん考えにあるとして、後はX-WSSE認証などの実装例も他のREST系のサービスなどで見ることができます。
実はこの辺りが、ADO.NET Data Serviceに残っている課題と言えるでしょう。

こうした話しを続けていくと、少しづつRESTfulな世界のイメージが湧いてくるのではないでしょうか？
RESTfulな設計には、いくつかの制限や原則がありますが、それを守っていくことで、複雑になってしまいがちな世界を牽制することができ、またそうした不自由さが新たな価値を生んでいくことに繋がると言えます。

次回は、ADO.NET Data Serviceのリンク（接続性）について考察してみたいと思います。

こだかたろう