ちょっとだいぶ遅くなったが、第３回RESTful読書会について書いてみる。
６章 読み取り/書き込み可能なリソース指向サービスの設計
@brownian さん担当。
５章で途中まで、RESTとして迷いなく進めるところまで設計した地図サービスを、「細かいところに目をつむって」一応完成してみたという内容。
７章 サービスの実装
@setoazusa さん担当。発表資料。
ブックマークサービスを Rails を用いて RESTful に実装してみたという内容。なぜ５・６章で設計した地図サービスを実装しなかったのかは謎。
この後８章が控えているからか、このあたりまで突っ込みおとなしめ……
８章 RESTとROAのベストプラクティス
RESTful Oriented Architecture のまとめと「ベストプラクティス」を紹介する内容。
id:ZIGOROu の資料は要所要所で本の内容に対する補足もあり、読了済みの人にも一見の値打ちはあるかと。これを一晩(＋他の人の発表の時間)でこしらえてしまうんだから参るよなあ。
というわけでこの８章、なかでも 8.8 節は全員から総攻撃を浴びていた。
集まった人たちがみんな特に意地悪だったかどうかはおいといて、8.8 節自体が弱点をさらけ出しすぎていて「右舷全砲門開け！ 打てば当たるぞ！」状態で自然な成り行きだったというか何というか。それにしてもみんな手加減しなさ過ぎ、開始早々ライフがゼロになっていたところにさらに迫撃砲を撃ち込みまくっていた。
読書会で出ていた 8.8 節 DIS られポイントを覚えている範囲で簡単にまとめ。
- 8.8.1 関係リソースを用いる理由付けにトランザクションを持ち出すのはどうか
- 8.8.2 非同期処理はアプリケーションのステートをリソースと見なすという話？
- 実際に RESTful にサービスを作るとそれなりに使う＞要ユースケース
- 8.8.3 一括処理は atomic であればわかるが、207(multi-status)を使うくらいなら２回リクエスト投げた方がいい。そのほうが REST らしい
- 8.8.4 そんなに言うなら実装してみろと小一時間(ry
- 「迷ったらリソース」と言いたくて、いかにも迷いそうなのを集めたんじゃない？
祭りになった最大の原因は、「ベストプラクティス」という割に納得させてくれないことだろう。いや、そもそも著者が納得している様子がない。
またほとんどの手段に対して現実的なユースケースが提示されていないため、読者はその手段を選択する理由付けに困ってしまい、「なんでそんなことをしないといけないの？」となってしまう。残念。
まあ REST についての本は本当にまだこれ一冊しかないという状況で贅沢言うなと思わないでもだが、逆にこれからRESTについて勉強でもしてみるかな、という人は必ずこの本を読むということで。
その際一番まずいシナリオは「うわ〜、RESTってこんなことしなきゃいけないんだ……ひくわー」だろう。そして RESTful 読書会の面々ですら引いちゃったわけだから、以下省略。
解消方法としては、(世の「ベストプラクティス」なるものが実のところ全てそうであるように)あくまで「ベタープラクティス」であることを明示しつつ、章の冒頭でどういうサービスや人ならRESTの採用を検討してみる価値があるかを記すというのを勝手に考えてみた。
- 不特定多数の他のユーザ・アプリケーション・サービスからの利用が想定されるサービス
- 将来、作り手の意図を越える使われ方をして未知の価値を生み出す夢を見たい人
- IR 対策の人(半分冗談です*1 )
そして、上記の「想定や夢があてはまる部分」について REST を検討することを勧めるのだ。
これだけで、あとの８章の内容はそのままでも、随分印象を変えることができると思うがどうだろう？
懇親会では一部の人が確変スーパーデレモードに突入していた。まあ、そういうこともあるということで。懇親会が配信されていなくて本当によかった。
