Signs;Gate〜RESTfulなサイトの作り方〜  Present by ぱろっと(@parrot_studio)          for Gunma.web #6            2011/09/03
Profile: T.Tachiki ぱろっと parrot_studio
Website: parrot-studio.com
シンプルかつWeb2.0っぽく作り直し
・ソーシャル系・制作物・過去のプレゼン等
詳しくはWebで    (´・ω・)っparrot-studio.com
Chapter 1:自己反省のプログラマ         “Fragments of Stars”,for RagnarokOnline Players with Astrology.
今回まずやるべきこと
“反省”
問題点1:最近ネタに走りすぎ(しかもすべり気味)
(今回も入れてるけど)  Σ(・ω・ノ)ノ
問題点2:LT=5分にこだわりすぎて詰め込みすぎ
前回の関数型とか端折りすぎ    (´-ω-)
それはまだしも、一番(゚д゚)マズーなこと
問題点3:理屈だけで「作ってない」
プログラマとしては大問題です・・・
そこで、真面目に新サイトをリリースしました    (´・ω・)っ
ROプレイヤーのための占星学サイト
“Fragments of Stars”  http://rostars.jp
・名前と星座を元にハッシュ計算して、“今日のおすすめ狩場”を提案・今日のレア予報・星座別プレイスタイル・占星学コラム(準備中)                 etc...
・・・それ、なんて診○メーカー?
否!
ちゃんと星座ごとに狩場を選んでいる(乙女座にここは合わないな・・・とか)      ( ゚д゚)o彡゚
すいません、基本は○断メーカーです    |ω・`)
それはさておき・・・
今回の開発で意識したこと
RESTful &  “Pure” Rails3
今日はこのお話 (´・ω・)っ
Chapter 2:電網世界のプリンシプル “REST” is principle of HTTP protocol,         on World Wide Web.
REST=Webの原則
Wikipedia:RESTRepresentational State Transfer(REST) は、ウェブのような分散ハイパーメディアシステムのためのソフトウェアアーキテクチャのスタイルのひとつである。この語は2000年に、HTTPプロ...
よくわからない・・・  (´-ω-)
RESTの代表的特徴
リソースを表現する “URI”       & 洗練された “メソッド”
URIUniform Resource Identifier
URIとリソース(≒データモデル)が1対1で対応
例:2010/8/5の群馬の気温 /temp/gunma/2010/8/5  #=> "36"
パラメータは表現方法を変えるだけ(指し示すリソースは変わらない)
表現が変わる例:/temp/gunma/2010/8/5?source=ntv #=> "56(-1)"
メソッドmethod:方法・方式
RESTのメソッドは8種類しかない
POST    - C(?)GET     -RPUT     -UDELETE - Dその他、HEAD・OPTIONS等
メソッド+リソースでリソースへの操作を表現
例:2010/8/5の気温を取得 GET /temp/gunma/2010/8/5メソッド リソース
例:2010/8/5の気温を削除DELETE /temp/gunma/2010/8/5メソッド   リソース
まさにAPI的(`・ω・´) b
「API」を公開するならRESTに従うのが大事
でも、HTMLのフォームにはGET/POSTしかない    Σ(゚Д゚)ガーン
・Railsなど(パラメータで指定)_method=PUT・Googleなど(ヘッダで指定)X-HTTP-Method-Override: PUT
まあ、フレームワークがよしなにやってくれる   (`・ω・´)
curlコマンドはメソッドを正しく扱える$ curl -X PUT http://hogehoge...
以上をふまえつつ・・・
「RESTfulに構築する」ということ
“機能やリソースに「名前=URI」を定義してしまう”
例:今日のおすすめ狩場POST /hunt/recommend ↓redirectGET /hunt/40/6
RESTを意識せず機能で表現された例
map_view.cgi?sign_id=6&map_id=40
・「機能」が主体になっている・パラメータによって「リソース」そのものが変わってしまう
なんかめんどくさい・・・   (´-ω-)
RESTfulに作ることの利点
1. 機能追加/連携しやすい
リソース+メソッドで機能が完結するので、現在の状態と関係なく他の機能を呼び出しやすい
2. URLの命名則がわかりやすい=ユーザビリティが高い
どっちがわかりやすい?p.miixii.jp/public/recent_page_feed.pl?page_id=1462   p.miixii.jp/public/recent/1462
3. ブックマークしやすい
4. SEO的に良い
5. Web2.0っぽい
6. カコ(・∀・)イイ!!
7. 彼女ができる
・・・すいません、最後のは嘘です   |ω・`)
そんなREST原則を破った有名なサイト
twitter.com/#!/parrot_studio
・# はフラグメントであってリソースではない(Ajaxで処理するという都合でこういう表現に)・#! はGoogleの都合で作られたルール
これが議論に・・・Σ(゚Д゚;≡;゚д゚)
Chapter 3:        単純明快のルート“Rails3” is more better, cool, sexy, RESTful than Rails2
(Ruby on )Rails: Rubyの用途として最大級の Webフレームワーク
Rails3 = Cool & Sexy       (*ノ∀ノ)
・Arel・Sexy Validation           etc...
しかし、Rails2と3の最大の差(だと私が感じたもの)
“routes”
routes: ルーティングを定める Railsの設定(ファイル)
Rails2 の routes
デフォルト:/controller/action/idControllerにactionを書けば動いちゃう
もうちょっと細かい指定map.connect /sign/:sign_id, :controller => ...
But...・機能が主体になりやすい・楽だけど、メソッドが不明確  (一目でわかりづらい)
Rails3 の routes
デフォルトはない(コメントアウト)
基本的な定義@Rails3# methodを明確にしているget /sign/:sign_id => sign#showpost /hunt/recommend => hunt#recommend# /hunt/recommend を「GET」...
明確!∠( ゚д゚)/
このへん、Sinatraの影響もあるかもget /sign/:sign_id do # 処理end
明確で簡潔な記述が(設計という)思考に影響を与える
「理想形」は連鎖するRails2 -> Sinatra -> Padrino      -> Merb-> Rails3 -> Rails3.1 ->    -> others...
Last Chapter:有形無人のレスポンサー    Epilogue and future.
言いたいことはただ一つ
“RESTfulに設計すると、「みんな」幸せ”    (`・ω・´) b
わかりやすい機能連携的に、ユーザ的に、API的に、SEO的に
カコ(・∀・)イイ!! Web技術者として
彼女ができる ヽ(*゚д゚)ノ
※ただし、イケメンに限る
(´・ω・`)
参考
one more thing...
次回:TwitterBOTの作り方(仮)
※予定は未定!!
まず完成させろ щ(゚Д゚щ)
ありがとうございました   (`・ω・´)ノ
Signs;Gate - RESTfulなサイトの作り方 (Gunma.web #6 2011/09/03)
Signs;Gate - RESTfulなサイトの作り方 (Gunma.web #6 2011/09/03)
Signs;Gate - RESTfulなサイトの作り方 (Gunma.web #6 2011/09/03)
Signs;Gate - RESTfulなサイトの作り方 (Gunma.web #6 2011/09/03)
Signs;Gate - RESTfulなサイトの作り方 (Gunma.web #6 2011/09/03)
Upcoming SlideShare
Loading in …5
×

Signs;Gate - RESTfulなサイトの作り方 (Gunma.web #6 2011/09/03)

2,337 views

Published on

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

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Signs;Gate - RESTfulなサイトの作り方 (Gunma.web #6 2011/09/03)

  1. 1. Signs;Gate〜RESTfulなサイトの作り方〜 Present by ぱろっと(@parrot_studio) for Gunma.web #6 2011/09/03
  2. 2. Profile: T.Tachiki ぱろっと parrot_studio
  3. 3. Website: parrot-studio.com
  4. 4. シンプルかつWeb2.0っぽく作り直し
  5. 5. ・ソーシャル系・制作物・過去のプレゼン等
  6. 6. 詳しくはWebで (´・ω・)っparrot-studio.com
  7. 7. Chapter 1:自己反省のプログラマ “Fragments of Stars”,for RagnarokOnline Players with Astrology.
  8. 8. 今回まずやるべきこと
  9. 9. “反省”
  10. 10. 問題点1:最近ネタに走りすぎ(しかもすべり気味)
  11. 11. (今回も入れてるけど) Σ(・ω・ノ)ノ
  12. 12. 問題点2:LT=5分にこだわりすぎて詰め込みすぎ
  13. 13. 前回の関数型とか端折りすぎ (´-ω-)
  14. 14. それはまだしも、一番(゚д゚)マズーなこと
  15. 15. 問題点3:理屈だけで「作ってない」
  16. 16. プログラマとしては大問題です・・・
  17. 17. そこで、真面目に新サイトをリリースしました (´・ω・)っ
  18. 18. ROプレイヤーのための占星学サイト
  19. 19. “Fragments of Stars” http://rostars.jp
  20. 20. ・名前と星座を元にハッシュ計算して、“今日のおすすめ狩場”を提案・今日のレア予報・星座別プレイスタイル・占星学コラム(準備中) etc...
  21. 21. ・・・それ、なんて診○メーカー?
  22. 22. 否!
  23. 23. ちゃんと星座ごとに狩場を選んでいる(乙女座にここは合わないな・・・とか) ( ゚д゚)o彡゚
  24. 24. すいません、基本は○断メーカーです |ω・`)
  25. 25. それはさておき・・・
  26. 26. 今回の開発で意識したこと
  27. 27. RESTful & “Pure” Rails3
  28. 28. 今日はこのお話 (´・ω・)っ
  29. 29. Chapter 2:電網世界のプリンシプル “REST” is principle of HTTP protocol, on World Wide Web.
  30. 30. REST=Webの原則
  31. 31. Wikipedia:RESTRepresentational 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の実例とはいえない。(以下略)
  32. 32. よくわからない・・・ (´-ω-)
  33. 33. RESTの代表的特徴
  34. 34. リソースを表現する “URI” & 洗練された “メソッド”
  35. 35. URIUniform Resource Identifier
  36. 36. URIとリソース(≒データモデル)が1対1で対応
  37. 37. 例:2010/8/5の群馬の気温 /temp/gunma/2010/8/5 #=> "36"
  38. 38. パラメータは表現方法を変えるだけ(指し示すリソースは変わらない)
  39. 39. 表現が変わる例:/temp/gunma/2010/8/5?source=ntv #=> "56(-1)"
  40. 40. メソッドmethod:方法・方式
  41. 41. RESTのメソッドは8種類しかない
  42. 42. POST - C(?)GET -RPUT -UDELETE - Dその他、HEAD・OPTIONS等
  43. 43. メソッド+リソースでリソースへの操作を表現
  44. 44. 例:2010/8/5の気温を取得 GET /temp/gunma/2010/8/5メソッド リソース
  45. 45. 例:2010/8/5の気温を削除DELETE /temp/gunma/2010/8/5メソッド リソース
  46. 46. まさにAPI的(`・ω・´) b
  47. 47. 「API」を公開するならRESTに従うのが大事
  48. 48. でも、HTMLのフォームにはGET/POSTしかない Σ(゚Д゚)ガーン
  49. 49. ・Railsなど(パラメータで指定)_method=PUT・Googleなど(ヘッダで指定)X-HTTP-Method-Override: PUT
  50. 50. まあ、フレームワークがよしなにやってくれる (`・ω・´)
  51. 51. curlコマンドはメソッドを正しく扱える$ curl -X PUT http://hogehoge...
  52. 52. 以上をふまえつつ・・・
  53. 53. 「RESTfulに構築する」ということ
  54. 54. “機能やリソースに「名前=URI」を定義してしまう”
  55. 55. 例:今日のおすすめ狩場POST /hunt/recommend ↓redirectGET /hunt/40/6
  56. 56. RESTを意識せず機能で表現された例
  57. 57. map_view.cgi?sign_id=6&map_id=40
  58. 58. ・「機能」が主体になっている・パラメータによって「リソース」そのものが変わってしまう
  59. 59. なんかめんどくさい・・・ (´-ω-)
  60. 60. RESTfulに作ることの利点
  61. 61. 1. 機能追加/連携しやすい
  62. 62. リソース+メソッドで機能が完結するので、現在の状態と関係なく他の機能を呼び出しやすい
  63. 63. 2. URLの命名則がわかりやすい=ユーザビリティが高い
  64. 64. どっちがわかりやすい?p.miixii.jp/public/recent_page_feed.pl?page_id=1462 p.miixii.jp/public/recent/1462
  65. 65. 3. ブックマークしやすい
  66. 66. 4. SEO的に良い
  67. 67. 5. Web2.0っぽい
  68. 68. 6. カコ(・∀・)イイ!!
  69. 69. 7. 彼女ができる
  70. 70. ・・・すいません、最後のは嘘です |ω・`)
  71. 71. そんなREST原則を破った有名なサイト
  72. 72. twitter.com/#!/parrot_studio
  73. 73. ・# はフラグメントであってリソースではない(Ajaxで処理するという都合でこういう表現に)・#! はGoogleの都合で作られたルール
  74. 74. これが議論に・・・Σ(゚Д゚;≡;゚д゚)
  75. 75. Chapter 3: 単純明快のルート“Rails3” is more better, cool, sexy, RESTful than Rails2
  76. 76. (Ruby on )Rails: Rubyの用途として最大級の Webフレームワーク
  77. 77. Rails3 = Cool & Sexy (*ノ∀ノ)
  78. 78. ・Arel・Sexy Validation etc...
  79. 79. しかし、Rails2と3の最大の差(だと私が感じたもの)
  80. 80. “routes”
  81. 81. routes: ルーティングを定める Railsの設定(ファイル)
  82. 82. Rails2 の routes
  83. 83. デフォルト:/controller/action/idControllerにactionを書けば動いちゃう
  84. 84. もうちょっと細かい指定map.connect /sign/:sign_id, :controller => ...
  85. 85. But...・機能が主体になりやすい・楽だけど、メソッドが不明確 (一目でわかりづらい)
  86. 86. Rails3 の routes
  87. 87. デフォルトはない(コメントアウト)
  88. 88. 基本的な定義@Rails3# methodを明確にしているget /sign/:sign_id => sign#showpost /hunt/recommend => hunt#recommend# /hunt/recommend を「GET」しても404になる
  89. 89. 明確!∠( ゚д゚)/
  90. 90. このへん、Sinatraの影響もあるかもget /sign/:sign_id do # 処理end
  91. 91. 明確で簡潔な記述が(設計という)思考に影響を与える
  92. 92. 「理想形」は連鎖するRails2 -> Sinatra -> Padrino -> Merb-> Rails3 -> Rails3.1 -> -> others...
  93. 93. Last Chapter:有形無人のレスポンサー Epilogue and future.
  94. 94. 言いたいことはただ一つ
  95. 95. “RESTfulに設計すると、「みんな」幸せ” (`・ω・´) b
  96. 96. わかりやすい機能連携的に、ユーザ的に、API的に、SEO的に
  97. 97. カコ(・∀・)イイ!! Web技術者として
  98. 98. 彼女ができる ヽ(*゚д゚)ノ
  99. 99. ※ただし、イケメンに限る
  100. 100. (´・ω・`)
  101. 101. 参考
  102. 102. one more thing...
  103. 103. 次回:TwitterBOTの作り方(仮)
  104. 104. ※予定は未定!!
  105. 105. まず完成させろ щ(゚Д゚щ)
  106. 106. ありがとうございました (`・ω・´)ノ

×