ADO.NET Data Service:RESTfulな実装について2
こんにちはこだかです。
前回の続きとして、今回はアドレス(アドレス可能性)について、お話したいと思います。
前回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では、リソース≒テーブル(ビジネスエンティティ)の世界を再び見せてくれるのですね。
なんだか元の鞘に戻った?感がある点です。
なんだか書いていて混乱してきました。
修行のため、もう少し続けてみようと思います。
こだかたろう
Comments
Anonymous
March 06, 2008
こんにちはこだかです。 前回 の続きとして、今回はアドレス(アドレス可能性)について、お話したいと思います。 前回RESTスタイルでの考え方としてリソースが主体になるという話がありました。 また、すべてのリソースにアドレスがあるという話も書きましたAnonymous
March 21, 2008
こんにちは、こだかです。 本来は「ADO.NET Data Serviceのリンク(接続性)」について書く予定だったのですが、改めて以前の書き込みを見直してみると、ちょっと誤解されるような内容がありましたので、今回は、