DoorKeeper
http://rubychildren.doorkeeper.jp/events/17514
ちなみに私、ちょうど会社でRESTの必要性に迫られて、以下の書籍で独学している最中なのです。
 | JavaによるRESTfulシステム構築 (2010/08/23) Bill Burke 商品詳細を見る |
この本は、JavaのRESTに関する仕様であるJAX-RSの本です。現在、読みながらちょとずつ写経中。
そんな私にとって、この勉強会はタイムリーなネタなのでした。
ちなみに前回も参加したかったんですが、他の勉強会と被ってしまって残念ながら行けなかったのでした。。。
なので今回が初参加。
この日は前半が「Webを支える技術」の読書会で、後半が @t_wada さんの講演でした。
とても参考になる勉強会だったので、当日のツイートをTogetterにも纏めてみました。
http://togetter.com/li/751922
■ 前半：「Webを支える技術」の読書会
以下の書籍をターゲットに、テーブルごとに読書とディスカッションを行いました。
 | Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus) (2010/04/08) 山本 陽平 商品詳細を見る |
今回は5章「URIの設計」が対象範囲でした。
まずRESTを学んで驚いたのが、URIを「設計する」という概念があることですね。
この章にも出てきますが、「Cool URIs don't change」（クールなURIは変わらない）とWebの発明者が論文で提唱してます。
あと、リダイレクトの仕組みを使ってURIの普遍性を維持する、というお話がありました。
これはちょうど職場で悩んでいた点だったので、とてもヒントになりました。
最後に質疑応答でAmazonのURLについて話がありましたが、これも興味深かったですねー
１つのリソースに複数のURLがある場合、<link rel="canonical">で代表URLを指定する、という仕組み、初めて知りました。
そしてAmazonでは、代表URLに敢えて長い、書籍名を含ませたURLを採用している点が興味深かったですね。
あと、同じリソースへのURLはできれば1種類がよい、というお話もありました。
■ 後半：「和田さんによるRESTfulな設計のお話・座談会
千駄ヶ谷.rbで講演されたときの資料をベースとした講演です。
すごく参考になった。以下、個人メモ。
---
■ 結論：RESTは麻疹である
- 良いものなので、早く感染して使いまくって、痛い目を見て卒業しましょう。
- 痛い目を見て、しばらく離れて、あとで戻ってくるくらいがちょうどいい。
■ URLに動詞が含まれていないか
- まずレビューすのが、URLに動詞が含まれていないか、という点。
- RESTの世界は動詞は５つくらいあればいい。他の動詞はいらない。
- URLに「edit」が含まれる場合は、「まあいいか」とすることもある。規約による妥協、という考え。
- なるべく名詞に近づける努力をする。
- loginは動詞じゃね？と調べてみると、そもそも「login」という英語はなく、logとinの合成後だった。
■ URLが無理な構造になっていないか
- 話し言葉みたいに読める、というのはURLにとっては大事でなはい。意味がわかることが大事。
- TumblrのURLは悪い例。
- コピー元とコピー先に上下関係にない。
- レビュー時は、URLの右にいくに従ってサブセットになっているかを見る。
- URLの左に行くほど偉い、右にいくほど偉くない。
- URLの名前探しには英英辞典や類義語辞典が便利。いつも辞書と共に設計をする。
- リソースとリソースの関係を探す第三のリソースを探す。
- 自分が知ってる単語から始まって、自分の知らない単語にどう辿り着くかが大事になってくる。
- HTTPメソッドが４つじゃ足りないよ、とよく言われる。（例：購読する、とか４つでできないじゃないか！）
- そこでまず考えていくのが、「自分がやりたいことが、何かを消したり更新したり、といった４つのどれに該当するだろうか」と思考を持っていくこと。
- 例えば「購読する」なら、「subscription」を「作ろう」としている、と考える。
- 例えば「属する」なら、「belong」という関係を「作る」と考える。「作る」が「入社」で、「消す」が「退社」になる。
- といったふうに、CRUDでけっこう表現できる。この思考を結構頑張ることが大事。
■ URLの意味と意思
- URLには、「意味を示す場所」と「意思を示す場所」がある。レビューではそれが混ざってないかを見ている。
- ?の前までは「リソースの意味」。?の後ろが「クライアントの意思」。
- ？以降をすべて取り去っても意味は変わらないか、?以前にリソースの意味と関係ない要素はないか、を見る。
- lang=jaとかは微妙で、グレーゾーン。
■ CRUDの重力に引かれていないか
- Webの４つのメソッドがRailsの６つのメソッドに対応づいている。
- 第3正規形のテーブルと１：１のrouteがあるのは粒度が細かすぎて、n+1問題にも容易に突き当たる。
- DBだけでなく、Webでもこの問題が出てきてしまう。
- DBの世界の粒度とWebの粒度は同じではない。
- どうやって１：１と１：１じゃない世界を結びつけたらいいのか、はcontrollerの仕事。
■ ステータスコードの選択
- そのリソースに対する操作がどうなったか、がWebの世界にはある。それがステータスコード。
- URL設計の壁を乗り越えていけば、ステータスコードも収束してくる。
- URL設計を頑張ると、その後は結構スイスイ行く。
- ステータスコードで障害の一時切り分けができる。
- 良くない設計は、ステータスコードを全部200で返して、レスポンスのJSONにエラーコードが入っている、とか。
- レスポンスの中を見ないと成功か失敗かが分からないし、コードの解釈も場面で変わるのでナンセンス。
- レスポンスの中身を見なくて、なにがどーなったかが分かる組みがWebにある。それがステータスコード。
- Railsはフレームワークまで例外が到達すると、ステータスコードに例外をマッピングして投げる。
- URLに含まれるのIDを１ずつズラしてアクセスしたり、アクセス権限がないけどリソースは存在、といった情報を知りたがる悪意に対処するために、ステータスコードをわざとズラして秘匿することがある。
■ 表現の設計
- 返ってくるJSONにURLが含まれてない、といったことがないかをレビューで見る。
- URLがないと、そこで袋小路で止まり、それ以降、辿れなくなる。
- URLが分からないものに対してURLを提供する。
■ 持続性のある表現のために
- 行き止まりを作らないようにする。選んで遷移できるようにする。
- サービスから送られてくるURLを使うことによってのみ遷移できるように考えてください。
- リンクがすごい大事。サーバから帰ってきたリンクで遷移先を決められるようにすること。
■ よくある議論
- 確認画面とかプレビュー画面のurlってどうやってるの？
- 階層構造だと、移動元と移動先、とか対等なものを表現するのに困るよね？
- 一部成功して一部失敗のときのレスポンスコードってどうするの？
- DBを移行して擬似キーのIDが変わったら、ぜんぶリンク切れになりました。。。
- クライアントかサーバか、どっちで処理するかは揺れる。フレームワークの種類によって大きく変わる。
- 時代はサーバである、クライアントである、と安易に言うのは思考停止でしかない。
- Twitterの @logout さんは、Twitter社は盲点だった。URLでログアウトしてしまう・・・
★感想：
ちょと前にRESTを学び始めた初学者の私にとって、すげー参考になる勉強会でした。
REST、URI、奥深し・・・。
あと和田さん、あるときはTDDだったり、DBだったり、RESTだったりと、毎回、技術の引き出し凄すぎやで。
そして勉強会が次回もあるなら、是非参加したいなぁ、と思うのでした。
あと、「Webを支える技術」と「JavaによるRestfullシステム構築」の２冊も、きちんと読んで写経しないと・・・
皆様、ありがとーございました。
- 関連記事
-
- 「システムテスト自動化カンファレンス2014」に参加しました
- 「RESTful#とは勉強会2」に参加しました
- SQLアンチパターン読書会 「マジックビーンズ(魔法の豆)」に参加しました
