Transcript 山本陽平の資料 xmldevday8

REST 入門
2005年11月24日 第八回 XML 開発者の日
株式会社リコー ソフトウェア研究開発本部
山本陽平
目次
•はじめに
• アーキテクチャスタイル
• REST の概要
• 例による REST (と SOAP の違い) の説明
• REST アーキテクチャスタイル
• まとめ
2005-11-24 第八回XML開発者の日
2
自己紹介
• ソフトウェア技術者、XML guy
• 1975年生まれ (同い年の人の例)
• 経験
http://d.hatena.ne.jp/Nayuta/20050727#1122477974
– Web/XML 関係でずーっと (1994年から)
– 画像機器上の Web 技術関係
• UPnP, SOAP, etc…
– Java で Web サービス開発
• Axis, etc…
• REST との出会い
– 2004年8月、村田さんの blog にて
– それまでは REST == XML-RPC だと思ってた
2005-11-24 第八回XML開発者の日
3
村田さんの blog
もしかして
今日がその日??
2005-11-24 第八回XML開発者の日
4
はじめに
• REST は～ではない
–
–
–
–
–
–
XML と HTTP の組み合わせではない
API の仕様ではない
W3C の仕様ではない
SOAP の対抗仕様ではない
SOA ではない
URL のパラメータをいじって XML データを得る方法ではない
• 今日の目的
– REST の誤解を解きたい
– アーキテクチャスタイルの重要性を共有したい
2005-11-24 第八回XML開発者の日
5
Representational State Transfer
• REST は WWW のアーキテクチャスタイル
– Roy Fielding (Apache.org の co-founder) の博士論文
• 残念ながら日本ではマイナー(だった)
– 海外では2002年ごろから盛り上がっている
– REST の歴史は1996年くらいから (HTTP/1.1 の策定とともに)
• REST スタイルを知っていると
–
–
–
–
–
Web アプリ/サービスのスケーラビリティが上がる、かもしれない
Web アプリ/サービスのユーザビリティが上がる、かもしれない
Web アプリ/サービスがセキュアになる、かもしれない
APP みたいなプロトコルを簡単に出せる、かもしれない
いわゆる疎結合が実現できる、かもしれない
2005-11-24 第八回XML開発者の日
6
目次
• はじめに
•アーキテクチャスタイル
• REST の概要
• 例による REST (と SOAP の違い) の説明
• REST アーキテクチャスタイル
• まとめ
2005-11-24 第八回XML開発者の日
7
アーキテクチャスタイルとは?
• 英語では “Architectural Style”
– ソフトウェア工学用語
• 別名(マクロ)アーキテクチャパターン
– アーキテクチャのパターン
– アーキテクチャそのものではないことに注意
• ミクロアーキテクチャパターン(デザインパターン)の親戚
– デザインパターンの方が細かいシステムを対象としている
• 代表的なアーキテクチャスタイル
– P2P、MVC、パイプ&フィルタ、クライアントサーバ
• 各スタイルはそれぞれ特徴的な制約の集合から成り立っている
– MVC: model, view, controller に役割を分担
– パイプ&フィルタ: コンポーネント間のデータの流れは一方向
2005-11-24 第八回XML開発者の日
8
目次
• はじめに
• アーキテクチャスタイル
•REST の概要
• 例による REST (と SOAP の違い) の説明
• REST アーキテクチャスタイル
• まとめ
2005-11-24 第八回XML開発者の日
11
リソース (1/3)
• REST における超重要な概念のひとつ
• リソースの例
–
–
–
–
–
東京の天気予報
2005年11月24日のスケジュール
新花巻駅の写真
Dijkstra著 ”Go To Statement Considered Harmful”
僕の最近のブックマーク
• リソース = 「名前」のつくありとあらゆる情報
• REST ではリソースをいろいろ操作する
2005-11-24 第八回XML開発者の日
12
リソース (2/3) 識別子
• すべてのリソースは識別子 (identifier) を持つ
– 一つのリソースに複数の識別子がつくこともある
• Web では URI
– 東京の天気予報
• http://weather.yahoo.co.jp/weather/jp/13/4410.html
– 2005年11月24日のスケジュール
• https://example.com/schedule/20051124
– 新花巻駅の写真
• http://www.flickr.com/photos/60043209@N00/6337155/
– Dijkstra 著 ”Go To Statement Considered Harmful”
• http://www.acm.org/classics/oct95/
– 僕の最近のブックマーク
• http://del.icio.us/yohei
2005-11-24 第八回XML開発者の日
13
リソース (3/3) 状態
• リソースは状態 (state) を持つ
– 時間や条件とともに内容が変化する可能性がある
– 「リソースの意味」は時間や条件によらず不変である
東京の明日の天気予報
(Resource)
1月5日 AM (明日は晴れそう)
Receiver
晴れ
時間による変化
1月5日 PM (明日は雨っぽい)
雨
ある時点における
リソースの状態の
具象的な表現
左から右に転送
• REST はリソースの representational state を transfer する
2005-11-24 第八回XML開発者の日
14
質問
• リソースの URI を与えられたら何をしますか?
– 東京の天気予報
• http://weather.yahoo.co.jp/weather/jp/13/4410.html
– 2005年11月24日のスケジュール
• https://example.com/schedule/20051124
これ
– 新花巻駅の写真
• http://www.flickr.com/photos/60043209@N00/6337155/
– Dijkstra 著 ”Go To Statement Considered Harmful”
• http://www.acm.org/classics/oct95/
– 僕の最近のブックマーク
• http://del.icio.us/yohei
2005-11-24 第八回XML開発者の日
16
URI の貼り付け == リソースの表現の取得
• URI があったらブラウザのアドレス欄に入れてみる
• これを REST 的に見ると
– URI (= リソースの識別子) を使って
– リソースのその時点での状態の表現を
– HTTP GET で取得
• している
• ネットサーフィン(死語)も本質的には同じ
– リンククリックやフォーム入力をトリガーに、リソースのある状態の表
現から(別の)リソースのある状態の表現に移る
• どんなリソースの URI でもアドレス欄に入力(HTTP GET)できる
のがすごいところ!
– 天気予報でも写真でも論文でも、 HTML でも PNG でも SWF でも
• なぜどんなリソースでも取得できるのか?
– リソースを操作するインターフェースが統一されているから
2005-11-24 第八回XML開発者の日
17
統一インターフェース (Uniform interface)
• REST を構成する超重要なスタイルの一つ
– HTML を取得するのが GET_HTML で、PDF を取得するのが
GET_PDF だったら、今の Web はどうなっていたでしょう?
• 統一されるのはコンポーネント間のインターフェース
– ブラウザ | プロクシ | リバースプロクシ | サーバ
• リソースを識別する統一的な識別子の存在
– URI
• 全てのリソースに適用できる洗練されたオペレーション (CRUD)
–
–
–
–
GET
PUT
DELETE
POST
リソースの取得
リソースの更新
リソースの削除
リソースの作成
(Retrieve)
(Update)
(Delete)
(Create …だけではない)
– 注意: この四つは特に重要。でも四つに限定しているわけではない
2005-11-24 第八回XML開発者の日
18
リンクをたどる -- ハイパーメディア
• A.html のリンクをクリックして B.html へ移動
– A というリソースの表現から B というリソースの表現へ移動
– クライアントのアプリケーションの状態が A から B になる
• リソース同士は単純に URI と HTTP (リンク)で結びついている
• 実はこれはすごいこと
– 中央リンク管理サーバやローカルリンク管理が必要ない
• URI さえあれば HTTP でリソースを操作できるので、アプリケー
ション連携がとても簡単
– いわゆる疎結合の実現
– 拡張性もあるよ！
2005-11-24 第八回XML開発者の日
19
ステートレス重要
• ステートレス = 状態なし
– メッセージ間のコミュニケーション状態がない
• 前のリクエストで××だったから、次のリクエストには○○で答え
る、という実装にしないですむ
– サーバ側でセッション管理しなくてよい
– 計算機リソースを解放できるので、スケーラビリティが向上
• ステートレスであるためには、リクエストメッセージは自己記述的で
ある必要がある
– Host ヘッダ、キャッシュ情報、認証情報、など
• クッキーや url-rewriting でのセッション管理は NG
2005-11-24 第八回XML開発者の日
20
目次
• はじめに
• アーキテクチャスタイル
• REST の概要
•例による REST
(と SOAP の違い)
の説明
• REST アーキテクチャスタイル
• まとめ
2005-11-24 第八回XML開発者の日
21
REST で Web サービス
• Atom Publishing Protocol っぽい例による Blog 編集
• リソースモデル
– エントリ(/entry/*): 各記事
• GET 記事の取得
• PUT 記事の更新
• DELETE 記事の削除
– エントリリスト(/entlylist): 記事一覧
/entry/0
REST入門
/entrylist
/entry/1
てゆーか…
日記一覧
• GET 一覧の取得
• POST 新記事の作成
/entry/2
ツイてる!
/entry/3
晩ご飯は…
2005-11-24 第八回XML開発者の日
22
エントリ一覧の取得 HTTP GET
GET /entrylist HTTP/1.1
Host: example.com
X-WSSE: UsernameToken…
各エントリへのハイパーリンク
HTTP/1.1 200 OK
Content-Type: application/atom+xml
<feed>
<title>yohei-y:weblog</title>
<entry>
<link href=“/entry/0”/>
</entry>
<entry>
<link href=“/entry/1”/>
</entry>
…
</feed>
リンクを辿る(href の URI を HTTP GETする)と…
2005-11-24 第八回XML開発者の日
23
エントリの取得 HTTP GET
GET /entry/0 HTTP/1.1
Host: example.com
X-WSSE: UsernameToken…
HTTP/1.1 200 OK
Content-Type: application/atom+xml
<entry>
<title>REST 入門</title>
<published
>2005-11-24T23:01:01</published>
<content>
<p>RESTは …</p>
</content>
</entry>
2005-11-24 第八回XML開発者の日
24
エントリの更新 HTTP PUT
PUT /entry/0 HTTP/1.1
Host: example.com
Content-Type: application/atom+xml
X-WSSE: UsernameToken…
HTTP/1.1 204 No Content
<entry>
<title>REST 入門</title>
<content>
<p>RESTとは …</p>
</content>
</entry>
2005-11-24 第八回XML開発者の日
25
エントリの削除 HTTP DELETE
DELETE /entry/0 HTTP/1.1
Host: example.com
X-WSSE: UsernameToken…
HTTP/1.1 204 No Content
2005-11-24 第八回XML開発者の日
26
エントリの新規作成 HTTP POST
POST /entrylsit HTTP/1.1
Host: example.com
Content-Type: application/atom+xml
X-WSSE: UsernameToken…
<entry>
<title>REST 入門</title>
<content>
<p>RESTとは …</p>
</content>
</entry>
HTTP/1.1 201 Created
Location: http://example.com/entry/5
新規作成されたリソースの URI
2005-11-24 第八回XML開発者の日
27
SOAP の場合 (クライアント側プログラム)
// サービスエンドポイントの初期化
BlogService bs = new BlogService(“http://example.com/servlet/blogservice”);
// セッション開始
String sid = bs.startSession(“yohei”, “abc123”);
// エントリ一覧の取得
Entry[] list = bs.getEntryList(sid);
String eid = list[0].getEntryId();
// 先頭エントリの取得
Entry item = bs.getEntry(sid, eid);
// エントリの更新
Item.setContent(“REST とは…”);
bs.putEntry(sid, eid, item);
// エントリの削除
bs.deleteEntry(sid, eid);
// エントリの追加
bs.postEntry(sid, item);
2005-11-24 第八回XML開発者の日
28
SOAP の場合 startSession
POST /servlet/blogservice HTTP/1.1 HTTP/1.1 200 OK
Host: example.com
Content-Type: application/soap+xml
Content-Type: application/soap+xml
<s:Envelope>
<s:Body>
<s:Envelope>
<m:startSessionResponse>
<s:Body>
<sid>123</sid>
<m:startSession>
</m:startSessionResponse>
<username>yohei</username>
</s:Body>
<passwd>hogehoge</passwd>
</s:Envelope>
</m:startSession>
</s:Body>
</s:Envelope>
セッションID
2005-11-24 第八回XML開発者の日
29
SOAP の場合 getEntryList
POST /servlet/blogservice HTTP/1.1 HTTP/1.1 200 OK
Host: example.com
Content-Type: application/soap+xml
Content-Type: application/soap+xml
<s:Envelope>
<s:Body>
<s:Envelope>
<m:getEntryListResponse>
<s:Body>
<entryList>
<m:getEntryList>
<entry><eid>1</eid>…<entry>
<sid>123</sid>
<entry><eid>2</eid>…</entry>
</m:getEntryList>
</entryList>
</s:Body>
</m:getEntryListResponse>
</s:Envelope>
</s:Body>
</s:Envelope>
セッションID
エントリ ID
2005-11-24 第八回XML開発者の日
30
SOAP の場合 getEntry
POST /servlet/blogservice HTTP/1.1 HTTP/1.1 200 OK
Host: example.com
Content-Type: application/soap+xml
Content-Type: application/soap+xml
<s:Envelope>
<s:Body>
<s:Envelope>
<m:getEntryResponse>
<s:Body>
<entry>
<m:getEntry>
<title>REST入門</entry>
<sid>123</sid>
<content>…</content>
<eid>1</eid>
</entryList>
</m:getEntry>
</m:getEntryResponse>
</s:Body>
</s:Body>
</s:Envelope>
</s:Envelope>
エントリ ID
2005-11-24 第八回XML開発者の日
31
SOAP の場合 putEntry
POST /servlet/blogservice HTTP/1.1 HTTP/1.1 200 OK
Host: example.com
Content-Type: application/soap+xml
Content-Type: application/soap+xml
<s:Envelope>
<s:Body>
<s:Envelope>
<m:putEntryResponse />
<s:Body>
</s:Body>
<m:putEntry>
</s:Envelope>
<sid>123</sid>
<eid>1</eid>
<entry>
<title>REST 入門</title>
<content>…</content>
</entry>
</m:putEntry>
</s:Body>
</s:Envelope>
2005-11-24 第八回XML開発者の日
32
SOAP の場合 deleteEntry
POST /servlet/blogservice HTTP/1.1 HTTP/1.1 200 OK
Host: example.com
Content-Type: application/soap+xml
Content-Type: application/soap+xml
<s:Envelope>
<s:Body>
<s:Envelope>
<m:deleteEntryResponse />
<s:Body>
</s:Body>
<m:deleteEntry>
</s:Envelope>
<sid>123</sid>
<eid>1</eid>
</m:deleteEntry>
</s:Body>
</s:Envelope>
2005-11-24 第八回XML開発者の日
33
SOAP の場合 postEntry
POST /servlet/blogservice HTTP/1.1 HTTP/1.1 200 OK
Host: example.com
Content-Type: application/soap+xml
Content-Type: application/soap+xml
<s:Envelope>
<s:Body>
<s:Envelope>
<m:postEntryResponse>
<s:Body>
<eid>5</eid>
<m:postEntry>
</m:postEntryResponse>
<sid>123</sid>
</s:Body>
<entry>
</s:Envelope>
<title>REST 入門</title>
<content>…</content>
</entry>
</m:postEntry>
</s:Body>
</s:Envelope>
2005-11-24 第八回XML開発者の日
34
REST (APP) と SOAP
REST
HTTP GET
HTTP GET
HTTP PUT
URI 1
entrylist
URI 2
entry
URI 3
entry
SOAP
HTTP POST
HTTP POST
getEntryList()
URI 1
End
point
getEntry(id)
putEntry(entry)
HTTP POST
2005-11-24 第八回XML開発者の日
35
REST と SOAP の違い
• SOAP では Web の世界 (HTTP/URI) と Web サービス世界
が分かれている
×SOAP
×SOAP
×SOAP
×SOAP
は全部 HTTP POST を使っている
はサービスごとの個別インターフェースがある
メッセージには URI (リンク) が入ってない
は HTTP をトランスポートプロトコルとして使う
• なぜ Web と Web サービスで世界を分けるのがだめなのか
– キャッシュ、階層化によるスケーラビリティ、プロクシによるアクセスコ
ントロール、・・・
• 詳しくは各アーキテクチャスタイルで
2005-11-24 第八回XML開発者の日
36
目次
• はじめに
• アーキテクチャスタイル
• REST の概要
• 例による REST (と SOAP の違い) の説明
• REST アーキテクチャスタイル
• まとめ
2005-11-24 第八回XML開発者の日
37
Client-Server (CS)
• ネットワークシステムで一番有名なスタイル
• 二つのコンポーネント
– サーバ: クライアントからのリクエストを待ちながらサービスを提供
– クライアント: サービスにリクエストを投げ、レスポンスを受け取る
• 制約: ユーザインターフェースとデータストレージの分離
server
client
• 特徴
○マルチプラットフォーム
○スケーラビリティ、サーバコンポーネントの単純化
2005-11-24 第八回XML開発者の日
38
Client-Stateless-Server (CSS)
• ステートレス: サーバでセッション状態を持たない
• 制約: リクエストには処理に必要な全ての情報を含む
client
server
client
client
• 特徴
○可視性: 一つのリクエストだけモニタリングすればよい
○信頼性: 部分的な失敗から回復 (最初からやり直さなくていい)
○スケーラビリティ: リソースをすぐに解放できる
×認証情報などを繰り返し送ることによるパフォーマンスの減少
2005-11-24 第八回XML開発者の日
39
Client-Cache-Stateless-Server (C$SS)
• キャッシュ: 同じリクエストは再利用する
• 制約: レスポンスがキャッシュ可能かどうかラベル付け (CacheControl, Expires, …)。キャッシュ可能なら、クライアント側で保
持
client $
server
client
client $
• 特徴
○サーバ、クライアントの対話を減らせる→パフォーマンス向上
×信頼性の低下 (情報が更新されないケース)
2005-11-24 第八回XML開発者の日
40
Uniform-Client-Cache-Stateless-Server (UC$SS)
• 統一インターフェース: REST を最も特徴付けるスタイル
• 制約: コンポーネント間のインターフェースを固定
＄
＄
• 特徴
サーバ内の
実装を隠蔽
＄
○アーキテクチャがシンプルに
○可視性の向上
○クライアント/サーバ実装の独立性向上
×情報粒度によってはトレードオフが発生
2005-11-24 第八回XML開発者の日
41
Uniform-Layered-Client-Cache-Stateless-Server (ULC$SS)
• 階層化システム: システムを複数階層に分割
• 制約: システムの知識を単一階層に限る
ゲートウェイ
＄
＄
$
プロクシ
$
＄
＄
＄
レガシーシステム
• 特徴
○コンポーネントの単純化 (他レイヤは知らなくてすむ)
○中間子の配置 (プロクシやロードバランサなど)
○レガシーシステムの封じ込め
×ネットワークオーバーヘッドによる待ち時間の増加
2005-11-24 第八回XML開発者の日
42
REST = Uniform-Layered-Code-on-Demand-ClientCache-Stateless-Server (ULCODC$SS)
• コードオンデマンド: クライアント側でコードをダウンロードして実行
(Flash, JavaScript)
• 実は REST では COD はオプション
＄
＄
$
$
＄
＄
＄
• 特徴
– ○クライアントを拡張できる
– ×可視性の低下
2005-11-24 第八回XML開発者の日
43
ネットワークシステムのアーキテクチャスタイル
Data-flow Style
Mobile Code Style
MA
PF
UPF
REST
U
VM
REV
COD
LCODC$SS
LC$SS
RS
Replication Style
CS
CSS
C$SS
LS
LCS
$
RR
RDA
Hierarchical Style
Peer-to-Peer Style
DO
BDO
2005-11-24 第八回XML開発者の日
C2
EBI
44
ネットワークシステムのアーキテクチャスタイル
• Data-flow Style
• Mobile Code Style
– Pipe and Filter (PF)
– Uniform Pipe and Filter (UPF)
• Replication Style
– Replicated Repository (RR)
– Cache ($)
• Hierarchical Style
–
–
–
–
–
Client-Server (CS)
Layered System (LS)
Layered Client-Server (LCS)
Client-Stateless-Server (CSS)
Client-Cache-Stateless-Server
(C$SS)
– Layered-Client-CacheStateless-Server (LC$SS)
– Remote Session (RS)
– Remote Data Access (RDA)
–
–
–
–
Virtual Machine (VM)
Remote Evaluation (REV)
Code on Demand (COD)
Layered-Code-on-DemandClient-Cache-Stateless-Server
(LCODC$SS)
– Mobile Agent (MA)
• Peer-to-Peer Style
–
–
–
–
Event-based Integration (EBI)
C2
Distributed Object (DO)
Brokered Distributed Object
(BDO)
• Rest
– Uniform interface (U)
2005-11-24 第八回XML開発者の日
45
まとめ
• REST は WWW のアーキテクチャスタイル
– REST を知らずして Web 2.0 を語ることなかれ
• REST では リソースが大切
• REST を構成する各制約の意味をきちんと把握しよう
– スペックだけみてても駄目
• アーキテクチャスタイル重要
– ソフトウェア技術者の基本的スキルとなる
2005-11-24 第八回XML開発者の日
46
おわり
2005-11-24 第八回XML開発者の日
47
2005-11-24 第八回XML開発者の日
48