自分も使いたいんだけど、使っていいのかな~。SQLのデータモデルクラスをそのままJSONで扱いたいけど、DataContractじゃないし、DataMemberついてもないからそのままだと使えなくて、でもそのためだけに別クラス作るのも馬鹿らしいじゃないっすか。みんなどうしてるんだろう。したらさ、ガスリー君(本物なのかな?)が言うんですよ。(...どういう意味?)。こんなに簡単に...。SimplyRestfulRouteHandlerを使えばいいよ!ってことですね。そもそもMVCContribってなんですか?ってなもんです。ソースをダウンロードして確認(現時点でのダウンロードが55っていうのが人気の無さを物語ってる気がしなくもなくもないけど気にしない!)。Methodだけで考えれば、リソースに対してGET/PUT/DELETE/POSTでアクションを決定するようにすればいいよね。ことはリソース=Actionじゃなくて、リソース=Controller。WebでHTMLをViewにする場合、入力ページ(新規と編集)もGETだからリソースのGETとかぶる。あと、コレクションのGETも。URIの設計をしてて思ったのは、URIのリソースをそのままコントローラと一致させないで、以下に内包したコントローラとして頭を切り替えるかが結構キモなんですね。/Companies/{companyId}/Employees/{employeeId}だけど、それぞれがコントローラになるんですよ~。/Employees/{employeeId}でも、これだと所属を表現できないからヤダってこともあるでしょう(会社と社員じゃないサンプルの方がよかったね...)。EmployeesController.Indexがそれぞれのコレクションリソースで、個別のリソースを取得するためにもうひとつModelアクションを定義。RoutingでうまくModelアクションにルーティングしてあげればうまいこと出来るよね。IDが123の会社削除こうしたいって時のコントローラでのアクション。※前回書いたRESTfulAttributeがある前提。{...}これをうまくRoutingでさばきます。});こうやって、2つのRoutingでひとつのコントローラに対する、ルーティングを登録すればIDのありなしをちゃんと1つのコントローラで処理できるから、なんて素敵にRESTful!ってなりませんかね。※正規表現はよしなに。ROAなURIを考えた場合{controller}/{action}/{id}だとアクションがリソースになるけど、{controller}/{id}/{action}でコントローラをリソースにしちゃいましょうっていう。});※コレクション部のルーティングも同じように。イロイロ内包するならたくさん書くか、"/Employees"を"/{controller}"にしてあげる。統一インターフェースでのアクセスは規約でアクションを決め打ちすることで最強になるでしょう。MVCContribの話じゃないっすね...。これを簡単にするのにMVCContrib。MethodとURIを見て、うまいことルーティングしてくれます。"_method"にメソッド名を入れてオーバーロードPOST。