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

前回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」になります。
ぐるっと一周まわって帰ってきた気分ですｗ

リソース主体の具体例を書いておきましょう。
例えば、人と言うリソースから、男性を検索したいと思います。
ビヘイビアベースでは、SearchPerson(Male)のようなサービスの戻りとして、結果を受けるはずです。（やり方は色々ありますが）
リソース主体の場合、人集合の男性結果を直接もらうイメージです。どこにあるの？と思うかもしれません。
ですから、リソース主体の場合はすべてのリソース(検索結果もリソース)に指し示すためのアドレスがあるのです。
この例ならば、～～/Person/Maleと言ったアドレスに結果があることになります。
検索と言う行為(ビヘイビア)がベースになるのではなく、リソースベースであることがご理解頂けるでしょうか？

次回は上記のアドレスの話をメインにADO.NET Data Serviceに触れていきますね。

こだかたろう