Gunma.web #6の資料 タイトルにあまり意味はないです

1. Signs;Gate
〜RESTfulなサイトの作り方〜
Present by ぱろっと(@parrot_studio)
for Gunma.web #6
2011/09/03

2. Profile:
T.Tachiki
ぱろっと
parrot_studio

3. Website：
parrot-studio.com

4. シンプルかつ
Web2.0っぽく作り直し

5. ・ソーシャル系
・制作物
・過去のプレゼン等

6. 詳しくはWebで
(´･ω･)っ
parrot-studio.com

7. Chapter 1:
自己反省のプログラマ
“Fragments of Stars”,
for RagnarokOnline Players with Astrology.

8. 今回まずやるべきこと

9. “反省”

10. 問題点1:
最近ネタに走りすぎ
（しかもすべり気味）

11. （今回も入れてるけど）
Σ(・ω・ノ)ノ

12. 問題点2:
LT=5分にこだわりすぎて
詰め込みすぎ

13. 前回の関数型とか端折りすぎ
(´-ω-)

14. それはまだしも、
一番(ﾟдﾟ)ﾏｽﾞｰなこと

15. 問題点3:
理屈だけで「作ってない」

16. プログラマとしては
大問題です・・・

17. そこで、真面目に
新サイトをリリースしました
(´･ω･)っ

18. ROプレイヤーのための
占星学サイト

19. “Fragments of Stars”
http://rostars.jp

21. ・名前と星座を元にハッシュ計算して、
“今日のおすすめ狩場”を提案
・今日のレア予報
・星座別プレイスタイル
・占星学コラム（準備中）
etc...

22. ・・・それ、
なんて診○メーカー？

23. 否！

24. ちゃんと星座ごとに狩場を選んでいる
（乙女座にここは合わないな・・・とか）
（ ﾟдﾟ）o彡ﾟ

25. すいません、
基本は○断メーカーです
|ω･`)

26. それはさておき・・・

27. 今回の開発で意識したこと

28. RESTful &
“Pure” Rails3

29. 今日はこのお話
(´･ω･)っ

30. Chapter 2:
電網世界のプリンシプル
“REST” is principle of HTTP protocol,
on World Wide Web.

31. REST=Webの原則

32. Wikipedia：REST
Representational State Transfer(REST) は、ウェブのような分散ハイパーメディアシステムのためのソフトウェアアーキテク
チャのスタイルのひとつである。この語は2000年に、HTTPプロトコル規格の主要著者の一人であるRoy Fieldingが、ウェブにつ
いて書いた博士論文で初めて現れ、ネットワーキングコミュニティの中ですぐに広く使われることになった。
RESTは、初めはアーキテクチャの原則と制約の集まり(後述)を指していたが、次第に、XMLやHTTPを使った簡易なウェブ
ベースのインターフェイスのうち、WebサービスのSOAPプロトコルのような MEP（Message Exchange Pattern; SOAPノード相互
のメッセージ交換のパターンを確立するための雛型）ベースの特別な抽象化をしないもののことを、大まかに意味する用語と
して使われるようになった。RESTは次に述べるように2つのやや異なる意味で使われている。
FieldingのRESTアーキテクチャスタイルの原則に合わせたWebサービスシステム。
RPCスタイルに合わせた簡易な XML+HTTP インターフェイスを採用したシステム(SOAPは使わない) 。
RESTはこのように2つのやや異なる意味で使われているため、技術的な議論の中で混乱を引き起こすことがある。 ただし、
RPCはRESTの実例とはいえない。（以下略）

33. よくわからない・・・
(´-ω-)

35. RESTの代表的特徴

36. リソースを表現する “URI”
&
洗練された “メソッド”

37. URI
Uniform Resource Identifier

38. URIとリソース（≒データモデル）が
1対1で対応

39. 例：2010/8/5の群馬の気温
/temp/gunma/2010/8/5
#=> "36"

40. パラメータは表現方法を変えるだけ
（指し示すリソースは変わらない）

41. 表現が変わる例：
/temp/gunma/2010/8/5?source=ntv
#=> "56(-1)"

42. メソッド
method：方法・方式

43. RESTのメソッドは
8種類しかない

44. POST - C(?)
GET -R
PUT -U
DELETE - D
その他、HEAD・OPTIONS等

45. メソッド＋リソースで
リソースへの操作を表現

46. 例：2010/8/5の気温を取得
GET /temp/gunma/2010/8/5
メソッド リソース

47. 例：2010/8/5の気温を削除
DELETE /temp/gunma/2010/8/5
メソッド リソース

48. まさにAPI的
(｀･ω･´) b

49. 「API」を公開するなら
RESTに従うのが大事

50. でも、HTMLのフォームには
GET/POSTしかない
Σ(ﾟДﾟ)ｶﾞｰﾝ

51. ・Railsなど（パラメータで指定）
_method=PUT
・Googleなど（ヘッダで指定）
X-HTTP-Method-Override: PUT

52. まあ、フレームワークが
よしなにやってくれる
(`･ω･´)

53. curlコマンドはメソッドを正しく扱える
$ curl -X PUT http://hogehoge...

54. 以上をふまえつつ・・・

55. 「RESTfulに構築する」
ということ

56. “機能やリソースに
「名前＝URI」を
定義してしまう”

57. 例：今日のおすすめ狩場
POST /hunt/recommend
↓redirect
GET /hunt/40/6

58. RESTを意識せず
機能で表現された例

59. map_view.cgi?sign_id=6&map_id=40

60. ・「機能」が主体になっている
・パラメータによって
「リソース」そのものが変わってしまう

61. なんかめんどくさい・・・
(´-ω-)

62. RESTfulに作ることの利点

63. 1. 機能追加/連携しやすい

64. リソース＋メソッドで機能が完結するので、
現在の状態と関係なく
他の機能を呼び出しやすい

65. 2. URLの命名則がわかりやすい
＝ユーザビリティが高い

66. どっちがわかりやすい？
p.miixii.jp/public/recent_page_feed.pl?page_id=1462
p.miixii.jp/public/recent/1462

67. 3. ブックマークしやすい

68. 4. SEO的に良い

69. 5. Web2.0っぽい

70. 6. ｶｺ（・∀・）ｲｲ!!

71. 7. 彼女ができる

72. ・・・すいません、
最後のは嘘です
|ω･`)

73. そんなREST原則を破った
有名なサイト

75. twitter.com/#!/parrot_studio

76. ・# はフラグメントであってリソースではない
（Ajaxで処理するという都合でこういう表現に）
・#! はGoogleの都合で作られたルール

77. これが議論に・・・
Σ(ﾟДﾟ；≡；ﾟдﾟ)

78. Chapter 3:
単純明快のルート
“Rails3” is more better, cool, sexy, RESTful than Rails2

79. (Ruby on )Rails:
Rubyの用途として最大級の
Webフレームワーク

80. Rails3 = Cool & Sexy
(*ﾉ∀ﾉ)

81. ・Arel
・Sexy Validation
etc...

82. しかし、Rails2と3の最大の差
（だと私が感じたもの）

83. “routes”

84. routes:
ルーティングを定める
Railsの設定（ファイル）

85. Rails2 の routes

86. デフォルト：/controller/action/id
Controllerにactionを書けば動いちゃう

87. もうちょっと細かい指定
map.connect '/sign/:sign_id', :controller => ...

88. But...
・機能が主体になりやすい
・楽だけど、メソッドが不明確
（一目でわかりづらい）

89. Rails3 の routes

90. デフォルトはない
（コメントアウト）

91. 基本的な定義@Rails3
# methodを明確にしている
get '/sign/:sign_id' => 'sign#show'
post '/hunt/recommend' => 'hunt#recommend'
# /hunt/recommend を「GET」しても404になる

92. 明確！
∠( ﾟдﾟ)／

93. このへん、Sinatraの影響もあるかも
get '/sign/:sign_id' do
# 処理
end

94. 明確で簡潔な記述が
（設計という）思考に
影響を与える

95. 「理想形」は連鎖する
Rails2 -> Sinatra -> Padrino
-> Merb
-> Rails3 -> Rails3.1 ->
-> others...

96. Last Chapter:
有形無人のレスポンサー
Epilogue and future.

97. 言いたいことは
ただ一つ

98. “RESTfulに設計すると、
「みんな」幸せ”
(｀･ω･´) b

99. わかりやすい
機能連携的に、
ユーザ的に、
API的に、
SEO的に

100. ｶｺ（・∀・）ｲｲ!!
Web技術者として

101. 彼女ができる
ヽ(*ﾟдﾟ)ノ

102. ※ただし、イケ
メンに限る

103. (´･ω･`)

104. 参考

106. one more thing...

108. 次回:
TwitterBOTの作り方（仮）

109. ※予定は未定!!

110. まず完成させろ
щ(ﾟДﾟщ)

111. ありがとうございました
(`･ω･´)ノ