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

  • Article

こんにちはこだかです。
前回の続きとして、今回はアドレス（アドレス可能性）について、お話したいと思います。

前回RESTスタイルでの考え方としてリソースが主体になるという話がありました。
また、すべてのリソースにアドレスがあるという話も書きました。

このアドレスですが、RESTスタイルでのリソースを指し示すものとして、URIが使用されます。
URIとは、URL + URN の事と理解して頂ければOKですが、URNと言うのは、NはNameを指しています。世界中で一意の名前との解釈で間違いありません。たとえばISBNなどはその例になります。
現状、RESTスタイルのWebServiceを考える場合、相手はWebですから、URI=URLと思って問題ないわけです。(本来の意味ではRESTはアーキテクチャースタイル、つまり「お作法」にあたり、その実装例としてWebがあります。)

アドレスの考え方として、すべてのリソースは少なくとも一つのアドレスを持つ必要があります。
例えば、前回のサンプルであった、人集合の中の男性をあらわすと、以下のようになるでしょう。
https://www.hogehoge.com/person/male
(ホスト名は適当です)

逆に、あるアドレスが複数のリソースを指すことはありません。
上記のアドレスが、男性と女性双方を表すことは、RESTスタイルではあってはいけないことなのですね。
ブックマークすれば、必ず同じ切り口でのリソースが取得できます。
これに違反している典型的な例は、Ajaxのサイトです。
同じURLですが、クライアントの要求によって刻々と見た目やデータが変化します。
ブックマークしても、同じ結果にはなりません。
こうした考え方もRESTスタイルが好まれる一因であります。

では、ADO.NET Data Serviceではどうでしょうか？
具体的な実装例はいずれお話するとして、今回は例として、Northwindデータベースをそのまま公開したとします。
以下はリソース取得の例です。

Categoriesテーブルの全レコードを取得
https://localhost/Northwind.svc/Categories

CategoriesテーブルのID=3レコードのCategoryNameフィールドの値を取得
https://localhost/Northwind.svc/Categories(3)/CategoryName

ProductsテーブルからUnitPriceフィールドが50より大きい結果を取得
https://localhost/Northwind.svc/Products?$filter=UnitPrice%20gt%2050

如何でしょうか？
このアドレスをブックマークすれば、常に同じ切り口でリソースが取得できることが保証されるわけです。
余談ですが、ADO.NET Data Serviceに対して、個人的に面白いというか混乱してしまうのは、
今までテーブル→ビヘイビアと言う、WebServiceでの考えかたのシフトがあり、そこにRESTでは、ビヘイビア→リソースと言う形で、同じく考え方を変える必要がありました。
しかし、ADO.NET Data Serviceでは、リソース≒テーブル(ビジネスエンティティ)の世界を再び見せてくれるのですね。
なんだか元の鞘に戻った？感がある点です。

なんだか書いていて混乱してきました。
修行のため、もう少し続けてみようと思います。

こだかたろう