Successfully reported this slideshow.

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

0

Share

Loading in …3
×
1 of 111
1 of 111

More Related Content

More from parrotstudio

Related Books

Free with a 14 day trial from Scribd

See all

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: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の実例とはいえない。(以下略)
  32. 32. よくわからない・・・ (´-ω-)
  33. 33. RESTの代表的特徴
  34. 34. リソースを表現する “URI” & 洗練された “メソッド”
  35. 35. URI Uniform 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 -R PUT -U DELETE - 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 ↓redirect GET /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/id Controllerに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#show' post '/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. ありがとうございました (`・ω・´)ノ

×