これはある意味関連リソースです

以前、私が書いたコラム「WPF ってUXだけのもの?」のアンサー(ではないような気がしますが)コラムが、エバンジェリスト大野によって書かれています。 「UX って見かけだけのもの?」 面白いエントリだと思います。両方を通してみると、WPFやUXの色々な顔が見えてきますね。 ちなみに、こだかは「REST ってなんだろう?」というコラムを書きました。 上記のように関連のあるリソースがブログなどでリンク(LINQではないです)されるのは、RESTっぽい考えですね。(誤解は承知です) ATOMでとった時の関連をTFサイトのコラムでも適用できないものか・・・ナムナム。

2

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

こんにちは、こだかです。 今回は、ADO.NET Data Serviceのリンク(接続性)について書きたいと思います。 RESTの実装としてのWebと言う話は以前したと思いますが、そのWebの便利な特徴としてハイパーリンクがあります。通常Webサーフィンをする場合、ハイパーリンクをたどって行くことで、様々な情報を入手することができるようになっています。当たり前と言えば当たり前ですが、この特徴は非常に重要です。もしリンクがなければ、常にアドレスを入力しなければいけませんよね。つまり、使いやすいリソース設計の条件に「リソース間のリンクを考える事」が必要になると言えます。そして、リソースの表現を受け取ったクライアントは、その中に含まれているリンクから、次のアクションを決定することができると言うわけです。(平たく言うと、Webアプリケーションの中で、「ブラウザの戻るボタンを押してください」とか、ブックマークにある別のアドレスに行く必要がある設計はイマイチってことですね)では、今回はSOAP形式のWebServiceを反例にして上記の優位点を確認しましょう。SOAP形式のWebServiceは、エンドポイントであるアドレスが一つだけあります。そして、そこに対して、Serviceのリクエストを出す形になります。このとき「そのServiceにはどのようなメソッドがあるのか?」は、まぁWSDLを見てくださいとなり、個々は独立していると言えます。例えば、SearchCategoryメソッドがあったとして、それでCategoryが取得できても、その関連であるProductの取得には、例えばSearchProductを行う必要があるかもしれません。そもそも、SearchCategory→SearchProductなんていう実装や順番は、このServiceのみのローカルルールであり、別のServiceを使用したい場合は、別のルールを理解する必要があるはずです・・・ 前置きが長くなりました。ADO.NET Data Serviceでは、AtomPubをリソースの表現として返すことができます。AtomPubは、主にブログなどの情報をやり取りすることが多いと思いますが、その中の要素として「link」があり、ここには、関連のあるWebリソースに対するリンクが入るようになっています。そして、ADO.NET Data Serviceも、そのルール通り、linkに対して関連する情報が入ります。関連する情報とは、ADO.NET Data Serviceの場合、公開されるのは論理層であるEDMなどですから、このEDMで定義したAssosiation(つまりリレーション)です。 実際にpubsデータベースのemployeeに対して、GETのリクエスト(http://localhost/Test2/pubs.svc/employee(‘PMA42628M’))をしてみました。 HTTP/1.1 200 OKCache-Control: no-cacheContent-Type: application/atom+xmlServer: Microsoft-IIS/7.0X-AspNet-Version: 2.0.50727X-Powered-By: ASP.NETDate: Fri, 21 Mar 2008 11:52:06 GMTContent-Length: 1096 ?<?xml version=”1.0″ encoding=”utf-8″ standalone=”yes”?><entry xml:base=”http://localhost/Test2/pubs.svc/” xmlns:ads=”http://schemas.microsoft.com/ado/2007/08/dataweb” xmlns:adsm=”http://schemas.microsoft.com/ado/2007/08/dataweb/metadata” adsm:type=”pubsModel.employee” xmlns=”http://www.w3.org/2005/Atom”>  <id>http://localhost/Test2/pubs.svc/employee(‘PMA42628M’)</id>  <updated />  <title />  <author>    <name />  </author>  <link rel=”edit” href=”employee(‘PMA42628M’)” title=”employee” />  <content type=”application/xml”>    <ads:emp_id>PMA42628M</ads:emp_id>    <ads:fname>Paolo</ads:fname>   …

1

ADO.NET Data Service:RESTfulな実装について5(2の補足)

こんにちは、こだかです。 本来は「ADO.NET Data Serviceのリンク(接続性)」について書く予定だったのですが、改めて以前の書き込みを見直してみると、ちょっと誤解されるような内容がありましたので、今回は、ADO.NET Data Service:RESTfulな実装について2の補足を書きたいと思います。 ADO.NET Data Service:RESTfulな実装について2の中で、アドレス可能ではない物として、Ajaxを例に出したのですが、実は、Ajaxを使っているサイトでもブックマーク可能である場合もあります。例えば、Google Mapなどは、クライアントが地図を操作した場合でも、そのときブラウザに表示してある地図のURLを表示することができるようになっています。そして、それをブックマークすればよいわけです。ですので、まぁ典型的な例としてAjaxがあるのですが、絶対不可能ではないと言うことです。ちょっと言葉足らずでした、すみません。 もう一つ。ブックマークすると、同じ切り口でリソースが取得できるとありました。これはどういうことでしょうか?例えば以下は前回の例です。 CategoriesテーブルのID=3レコードのCategoryNameフィールドの値を取得http://localhost/Northwind.svc/Categories(3)/CategoryName ここから得られる結果の元ネタは、Northwindデータベースにあるデータです。したがって、そのデータは変化している可能性があります。今日取得した結果と明日取得した結果は異なるかもしれないと言うことですよね。 この辺りでちょっと混乱するかもしれません。リソースにアドレスがあるからこそ、ブックマークも可能であったはずです。なのに、同じ結果が得られない??実は、リソースには状態(state)と言う考え方があり、時間や条件により内容が変化することがあるのです。リソースで普変であるのは、その「意味」になります。前回「同じ切り口で~」と書いた部分がこれにあたり、この「状態」の話は別の機会にするつもりだったのですが、これも誤解を招くように思いましたので、書かせていただきました。 したがって、上記の例では「CategoriesテーブルのID=3レコードのCategoryNameフィールドの値」と言う意味自体は当然変わりませんが、データ(状態)は変化するかもしれないと言うことになります。 RESTと言う言葉の意味は「Representational State Transfer」であり、その意味は「表現可能な状態の転送」となります。まさに、リソースの状態を転送することを指しているのですね。 こだかたろう


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

こんにちは、こだかです。 今回は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のリンク(接続性)について考察してみたいと思います。 こだかたろう


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

こんにちは、こだかです。 今回は「1)RESTfulな実装」の中から、「戻りはAtomPub JSONフォーマット」の部分をご紹介します。 RESTfulな世界では「リソースが主体になる」と言うお話を以前書きましたが、このリソースとは設計者が考えたメタデータです。と言うか、カタカナで書くと私がよくわからないwので、誤解を覚悟で書くと、設計者が扱いたい対象そのものをリソースと呼ぶことにしましょう。リソースを主体としたServiceを構築する場合、当然そのリソースは、最終的にServiceを利用するクライアントのPC上で扱われることになりますので、特定のフォーマットや言語で提供する必要があります。例えば、XML、プレーンテキスト、CSV、Webページそのものなど、様々な表現方法が考えられますよね。 では、Serviceが表現方法を複数提供できる場合、クライアントがどのように要求するべきか?を考えてみることにしましょう。まず、表現ごとにアドレスを分ける方法が考えられます。例えば、人集合の中の男性を表す場合、以下のように個別のURLを割り当てることで実装する方法です。XMLで出力 http://www.hogehoge.com/person/male.xmlHTMLで出力 http://www.hogehoge.com/person/male.html 前回、「リソースは少なくとも一つのアドレスを持つ必要があります。」と書きましたが、これは複数のアドレスが同じリソースを指している例になります。ただ問題は、アドレスが別れている為に、使用者が別のリソースと勘違いする可能性がある点ですね。(こういった観点からも、リソース主体の設計ではアドレスの付け方にセンスが要求されます。)なお、この考え方で複数の表現方法に対して対応を行っているのが、Ruby on Rails のActiveResourceです。もう一つの方法としては、HTTP content-type negotiationの使用が考えられます。これは、HTTPのリクエストヘッダーにフォーマットなどの指定を記述する方法です。身近な例では、Webブラウザの言語を切り替えることによって、Webサイトの言語が変わる等は経験があるのではないでしょうか?ちなみに、ADO.NET Data Serviceの対応はこちらになり、AtomPubとJSONをサポートしています。 上記の例であれば、URLはhttp://www.hogehoge.com/person/maleで共通ですが、HTTPのリクエストヘッダーにフォーマットを記述することで、表現の切り替えが可能だと言うことですね。 では、実行例をご覧頂きましょう。ADO.NET Data Serviceで作成したService http://localhost/test/jinji.svcに対してGET(http://localhost/test/jinji.svc/job(101))をリクエストしてみました。HTTP content-type negotiationを指定したいので、Webブラウザではなく、Fiddlerと言うツールを使用しています。(画像はクリックすると拡大します)AtomPub Json jsonの例の中でHTTPヘッダーに、「Accept: application/json」とありますが、これが指定部分です。(AtomPubは省略可能)この考え方が進んで行けば、クライアントは人/プログラムを問わないと言う、Service実装も考えられるのですが、現状そこまで可能な例はあまりないと思います。(ADO.NET Data Serviceで実装できているわけではありませんのでご注意を・・・) こだかたろう

2

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

こんにちはこだかです。前回の続きとして、今回はアドレス(アドレス可能性)について、お話したいと思います。前回RESTスタイルでの考え方としてリソースが主体になるという話がありました。また、すべてのリソースにアドレスがあるという話も書きました。このアドレスですが、RESTスタイルでのリソースを指し示すものとして、URIが使用されます。URIとは、URL + URN の事と理解して頂ければOKですが、URNと言うのは、NはNameを指しています。世界中で一意の名前との解釈で間違いありません。たとえばISBNなどはその例になります。現状、RESTスタイルのWebServiceを考える場合、相手はWebですから、URI=URLと思って問題ないわけです。(本来の意味ではRESTはアーキテクチャースタイル、つまり「お作法」にあたり、その実装例としてWebがあります。)アドレスの考え方として、すべてのリソースは少なくとも一つのアドレスを持つ必要があります。例えば、前回のサンプルであった、人集合の中の男性をあらわすと、以下のようになるでしょう。http://www.hogehoge.com/person/male(ホスト名は適当です)逆に、あるアドレスが複数のリソースを指すことはありません。上記のアドレスが、男性と女性双方を表すことは、RESTスタイルではあってはいけないことなのですね。ブックマークすれば、必ず同じ切り口でのリソースが取得できます。これに違反している典型的な例は、Ajaxのサイトです。同じURLですが、クライアントの要求によって刻々と見た目やデータが変化します。ブックマークしても、同じ結果にはなりません。こうした考え方もRESTスタイルが好まれる一因であります。では、ADO.NET Data Serviceではどうでしょうか?具体的な実装例はいずれお話するとして、今回は例として、Northwindデータベースをそのまま公開したとします。以下はリソース取得の例です。Categoriesテーブルの全レコードを取得http://localhost/Northwind.svc/CategoriesCategoriesテーブルのID=3レコードのCategoryNameフィールドの値を取得http://localhost/Northwind.svc/Categories(3)/CategoryNameProductsテーブルからUnitPriceフィールドが50より大きい結果を取得http://localhost/Northwind.svc/Products?$filter=UnitPrice%20gt%2050如何でしょうか?このアドレスをブックマークすれば、常に同じ切り口でリソースが取得できることが保証されるわけです。余談ですが、ADO.NET Data Serviceに対して、個人的に面白いというか混乱してしまうのは、今までテーブル→ビヘイビアと言う、WebServiceでの考えかたのシフトがあり、そこにRESTでは、ビヘイビア→リソースと言う形で、同じく考え方を変える必要がありました。しかし、ADO.NET Data Serviceでは、リソース≒テーブル(ビジネスエンティティ)の世界を再び見せてくれるのですね。なんだか元の鞘に戻った?感がある点です。なんだか書いていて混乱してきました。修行のため、もう少し続けてみようと思います。こだかたろう

2

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

こんにちは、こだかです。 前回ADO.NET Data Serviceの話を書きましたが、あまりにも乱暴すぎたような気がしておりまして、もう少し細かくお話させてください。 今回は、「1)RESTfulな実装」の中から、「・HTTPのverbすなわちGET PUT POST DELETEのみのインターフェイス」の部分に触れてみます。 従来SOAPでサービスを作成する場合、そのサービスの振舞いを名前として公開する形が多かったと思います。もっと言うと、初めに動詞が着いたサービス名ですね。Search○○、Update○○などと言った感じです。これは自由度があっていいのですが、一方で多くの切り口でサービスが作られてしまい、混乱する可能性も捨てきれません。RESTスタイルでは、これをリソース主体で考えます。○○をSearchするのではなく、Searchした結果(のリソース)を取得する。と言った考え方になります。 さて、このリソースに存在する機能ですが、例えば、データベースのテーブルを考えて見ましょう。データベースに対して、一般的に必要とされる機能はCRUDと言われています。「作成(Create)」「読み出し(Read)」「更新(Update)」「削除(Delete)」の頭文字ですが、これは「INSERT」「SELECT」「UPDATE」「DELETE」が対応しますよね。 そして、同じようにRESTスタイルのリソースにもCRUDとして機能が定義できます。これがHTTPのGET PUT POST DELETEに当たる訳です。順番を考慮するならば、POST(追加) GET(取得) PUT(更新) DELETE(削除)になります。機能としてこれ以外のコマンドは使用しませんが、そうして特定された考え方が、結果として整理された設計や実装に繋がるのです。SOAP:=振る舞い(ビヘイビア)ベース、RESTful:=リソースベースのサービスと言う事がここからも言える訳ですね。 ADO.NET Data Serviceでは、このリソースがEDMで定義されたビジネスエンティティにあたります。これは、EDMとテーブルを1対1にすれば、まさにテーブルがリソースになり、RESTfulで言うところのCRUDは、そのままテーブルの「INSERT」「SELECT」「UPDATE」「DELETE」になります。ぐるっと一周まわって帰ってきた気分ですw リソース主体の具体例を書いておきましょう。例えば、人と言うリソースから、男性を検索したいと思います。ビヘイビアベースでは、SearchPerson(Male)のようなサービスの戻りとして、結果を受けるはずです。(やり方は色々ありますが)リソース主体の場合、人集合の男性結果を直接もらうイメージです。どこにあるの?と思うかもしれません。ですから、リソース主体の場合はすべてのリソース(検索結果もリソース)に指し示すためのアドレスがあるのです。この例ならば、~~/Person/Maleと言ったアドレスに結果があることになります。検索と言う行為(ビヘイビア)がベースになるのではなく、リソースベースであることがご理解頂けるでしょうか?次回は上記のアドレスの話をメインにADO.NET Data Serviceに触れていきますね。 こだかたろう

2

マイクロソフトRESTへの注力?

先日、眼病の手術があり、強烈な頭痛に悩まされているこだかです。実はこの1年で、3回の手術を受けていたのでした。これで落ち着くと思いたいのですが・・・非常にもどかしいのです。 さて、3/5-3/7にかけてラスベガスでMIX08が開催されます。 このイベントは毎年開催されるWeb開発系のもので、昨年はSilverlightの発表がありました。(この時Astoria=ADO.NET Data Serviceも発表になっています) 今年ですが、色々発表される中で、Windows Liveに対する事前発表があり(http://dev.live.com/blogs/devlive/archive/2008/02/27/213.aspx)、その中でAtomPubやADO.NET Data Servicesについても触れています。これによると、AtomPubのendpointを持ったWindows LiveのServiceが実装されるようです。 また、Project Astoria Team Blog(http://blogs.msdn.com/astoriateam/archive/2008/02/29/mix08-is-almost-here.aspx)を見ると、今回のMIXでRESTfulなDataService関係のセッションが3つもあるとの事で、力の入れ具合が伝わってくるようです。 以前のPOSTでも書きましたが、上記のようなServiceを紹介する場合、SOAP=Strict、REST=Flexibleと言った切り口でお話させて頂くと思いますが、この力の入れようには少々戸惑いも感じつつ・・・なんて私の立場で書くと怒られてしまいそうですね。 こだかたろう

1