Advertisement
Advertisement

More Related Content

Advertisement

More from parrotstudio(15)

Recently uploaded(20)

Advertisement

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

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