Home
Explore
Submit Search
Upload
Login
Signup
Advertisement
Check these out next
研究会20140702:進捗報告
Peinan ZHANG
~knitr+pandocではじめる~『R MarkdownでReproducible Research』
Nagi Teramo
R3.0.0 is relased
Shintaro Fukushima
エラーハンドリング
道化師 堂華
Ilerpg Study 003
Yoshiki Ushida
ZFSのソースコードをチラ見してみる
Koichi Suzuki
Goroutineとchannelから始めるgo言語@初心者向けgolang勉強会
Takuya Ueda
Ilerpg Study 004
Yoshiki Ushida
1
of
111
Top clipped slide
Signs;Gate - RESTfulなサイトの作り方 (Gunma.web #6 2011/09/03)
Sep. 7, 2011
•
0 likes
0 likes
×
Be the first to like this
Show More
•
1,447 views
views
×
Total views
0
On Slideshare
0
From embeds
0
Number of embeds
0
Download Now
Download to read offline
Report
Technology
Gunma.web #6の資料 タイトルにあまり意味はないです
parrotstudio
Follow
Advertisement
Advertisement
Advertisement
Recommended
LLdeade Python Language Update
Atsushi Shibata
2.4K views
•
30 slides
2008.10.18 L4u Tech Talk
mitamex4u
2.3K views
•
78 slides
Coq 20100208a
tmiya
3.7K views
•
36 slides
研究会20140618:進捗と闇Pythonistaのワンライナーテクニックを少々
Peinan ZHANG
3.7K views
•
21 slides
Ilerpg Study 006
Yoshiki Ushida
583 views
•
9 slides
Rでreproducible research
Shintaro Fukushima
7.9K views
•
38 slides
More Related Content
Slideshows for you
(10)
研究会20140702:進捗報告
Peinan ZHANG
•
427 views
~knitr+pandocではじめる~『R MarkdownでReproducible Research』
Nagi Teramo
•
31.3K views
R3.0.0 is relased
Shintaro Fukushima
•
4.6K views
エラーハンドリング
道化師 堂華
•
2.8K views
Ilerpg Study 003
Yoshiki Ushida
•
879 views
ZFSのソースコードをチラ見してみる
Koichi Suzuki
•
1.2K views
Goroutineとchannelから始めるgo言語@初心者向けgolang勉強会
Takuya Ueda
•
17K views
Ilerpg Study 004
Yoshiki Ushida
•
1.8K views
Rcppのすすめ
Masaki Tsuda
•
14K views
Tokyo.R #19 発表資料 「Rで色々やってみました」
Masayuki Isobe
•
4.1K views
Similar to Signs;Gate - RESTfulなサイトの作り方 (Gunma.web #6 2011/09/03)
(10)
いまさら聞けないRake入門
Tomoya Kawanishi
•
11.4K views
GAE/GoでWebアプリ開発入門
Takuya Ueda
•
8.3K views
C++コミュニティーの中心でC++をDISる
Hideyuki Tanaka
•
12.3K views
Wp プラグインapiから理解するword press.share
Yuji Nojima
•
8.5K views
G検定傾向と対策_pythonguild#3LT
Hide Fukano
•
79 views
groovy 2.1.0 20130118
Uehara Junji
•
3.5K views
Example using LattePanda
Hirokazu Egashira
•
367 views
PECL operator で演算子オーバーロード
y-uti
•
1.3K views
rpi_handson_2.5
teruyaono1
•
49 views
C++のライブラリを簡単に眺めてみよう
Hiro H.
•
5.2K views
Advertisement
More from parrotstudio
(15)
"プロのプログラマ"を目指す初心者が最初に読むべきたった一冊の本
parrotstudio
•
5.1K views
希望の関数と絶望の副作用
parrotstudio
•
2.2K views
「もうなにもこわくない」関数型言語 〜ふつうのプログラマが関数型言語を知るべき理由・reload〜
parrotstudio
•
2.3K views
ぱろっと、Padrinoやめるってよ
parrotstudio
•
2K views
エンジニアがTRPGをやるべき理由 〜隣り合わせの遊びと技術〜 (Gunma.web #12 2013/02/09)
parrotstudio
•
1.8K views
(´・ω・`)としたーは衰退しました (Gunma.web #11 2012/11/23)
parrotstudio
•
1.1K views
私に作る時間がないのはどう考えても仕事が悪い!? (Gunma.web #10 2012/09/08)
parrotstudio
•
949 views
ネタプログラミング言語クリエイターYouma (Gunma.web #8 2012/03/03)
parrotstudio
•
2K views
プログラマになれないあなたのための言語戦略 (Gunma.web #7 2011/12/17)
parrotstudio
•
1.4K views
「再代入なんて、あるわけない」 ~ふつうのプログラマが関数型言語を知るべき理由~ (Gunma.web #5 2011/05/14)
parrotstudio
•
15.2K views
思い通りにいかないのがWebなんて 割り切りたくないから (Gunma.web #4 2011/02/12)
parrotstudio
•
824 views
俺の体がこんなにすっきりしているわけがない ~5分でわかる催眠プログラミング~ (Gunma.web #3 2010/12/11)
parrotstudio
•
2.3K views
「一番いいおすすめを頼む」 ~5分でわかるレコメンドエンジンの基礎~ (Gunma.web #3 2010/12/11)
parrotstudio
•
4.9K views
これからのJSの話をしよう ~jQueryで作るTwitterアプリ~ (Gunma.web #2 2010/10/9)
parrotstudio
•
1.5K views
どきっ!三行で作るランダムダンジョン!?~WEBもあるよ!~ - 2010/8/21 群馬Web研究会(勉強会)
parrotstudio
•
1.2K views
Recently uploaded
(20)
Transformerについて解説!!
Yosuke Horio
•
10 views
JSAI2023_企画セッション(仕掛学)資料
Matsushita Laboratory
•
45 views
【DL輪読会】DINOv2: Learning Robust Visual Features without Supervision
Deep Learning JP
•
93 views
GraalVMでのFlight Recorderを使ったパフォーマンス解析(JJUG CCC 2023 Spring)
NTT DATA Technology & Innovation
•
12 views
mi-6. 画像分類システム
kunihikokaneko1
•
4 views
通信プロトコルについて
iPride Co., Ltd.
•
7 views
CDLEハッカソン2022参加報告.pdf
SHOIWA1
•
10 views
【DL輪読会】大量API・ツールの扱いに特化したLLM
Deep Learning JP
•
270 views
社内ソフトスキルを考える
infinite_loop
•
91 views
【DL輪読会】Egocentric Video Task Translation (CVPR 2023 Highlight)
Deep Learning JP
•
101 views
3Dプリンタって いいね
infinite_loop
•
64 views
DrupalをDockerで起動してみる
iPride Co., Ltd.
•
22 views
HTTPの仕組みについて
iPride Co., Ltd.
•
12 views
mi-8. 人工知能とコンピュータビジョン
kunihikokaneko1
•
7 views
mi-4. 機械学習
kunihikokaneko1
•
4 views
量子論.pdf
hiro150493
•
9 views
GitHub と Azure でアプリケーションとインフラストラクチャの守りを固めるDevSecOps
Kazumi IWANAGA
•
6 views
【DL輪読会】HyperDiffusion: Generating Implicit Neural Fields withWeight-Space Dif...
Deep Learning JP
•
19 views
OIDC(OpenID Connect)について解説③
iPride Co., Ltd.
•
25 views
Windows ChatGPT Bing AI.pptx
Atomu Hidaka
•
7 views
Advertisement
Signs;Gate - RESTfulなサイトの作り方 (Gunma.web #6 2011/09/03)
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: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の実例とはいえない。(以下略)
よくわからない・・・ (´-ω-)
RESTの代表的特徴
リソースを表現する “URI”
& 洗練された “メソッド”
URI Uniform 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 -R PUT -U DELETE - 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 ↓redirect GET
/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/id Controllerにactionを書けば動いちゃう
もうちょっと細かい指定 map.connect '/sign/:sign_id', :controller
=> ...
But... ・機能が主体になりやすい ・楽だけど、メソッドが不明確 (一目でわかりづらい)
Rails3 の routes
デフォルトはない (コメントアウト)
基本的な定義@Rails3 # methodを明確にしている get '/sign/:sign_id'
=> 'sign#show' post '/hunt/recommend' => 'hunt#recommend' # /hunt/recommend を「GET」しても404になる
明確! ∠( ゚д゚)/
このへん、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の作り方(仮)
※予定は未定!!
まず完成させろ щ(゚Д゚щ)
ありがとうございました
(`・ω・´)ノ
Advertisement