REST 入門

REST 入門株式会社リコーソフトウェア研究開発本部山本陽平 2005 年 11 月 24 日第八回 XML 開発者の日

目次はじめにアーキテクチャスタイル REST の概要例による REST (と SOAP の違い) の説明 REST アーキテクチャスタイルまとめ

自己紹介ソフトウェア技術者、 XML guy 1975 年生まれ ( 同い年の人の例 )  経験 Web/XML 関係でずーっと (1994 年から ) 画像機器上の Web 技術関係 UPnP, SOAP, etc… Java で Web サービス開発 Axis, etc… REST との出会い 2004 年 8 月、村田さんの blog にてそれまでは REST == XML-RPC だと思ってた http://d.hatena.ne.jp/Nayuta/20050727#1122477974

村田さんの blog もしかして今日がその日 ??

はじめに REST は～ではない XML と HTTP の組み合わせではない API の仕様ではない W3C の仕様ではない SOAP の対抗仕様ではない SOA ではない URL のパラメータをいじって XML データを得る方法ではない今日の目的 REST の誤解を解きたいアーキテクチャスタイルの重要性を共有したい

Representational State Transfer REST は WWW のアーキテクチャスタイル Roy Fielding (Apache.org の co-founder) の博士論文残念ながら日本ではマイナー ( だった ) 海外では 2002 年ごろから盛り上がっている REST の歴史は 1996 年くらいから (HTTP/1.1 の策定とともに ) REST スタイルを知っていると Web アプリ / サービスのスケーラビリティが上がる、かもしれない Web アプリ / サービスのユーザビリティが上がる、かもしれない Web アプリ / サービスがセキュアになる、かもしれない APP みたいなプロトコルを簡単に出せる、かもしれないいわゆる疎結合が実現できる、かもしれない

アーキテクチャスタイルとは? 英語では “Architectural Style” ソフトウェア工学用語別名(マクロ)アーキテクチャパターンアーキテクチャのパターンアーキテクチャそのものではないことに注意ミクロアーキテクチャパターン(デザインパターン)の親戚デザインパターンの方が細かいシステムを対象としている代表的なアーキテクチャスタイル P2P、MVC、パイプ&フィルタ、クライアントサーバ各スタイルはそれぞれ特徴的な制約の集合から成り立っている MVC: model, view, controller に役割を分担パイプ&フィルタ: コンポーネント間のデータの流れは一方向

REST はネットワークシステムのアーキテクチャスタイル特に WWW のアーキテクチャスタイル (WWW は REST のインスタンス ) クラサバ (CS) から派生した複合型スタイル

余談: 訳語について Architectural style の訳語は ? (mixi の REST コミュで聞いてみた ) アーキテクチャ的スタイルアーキテクチャのスタイルアーキテクチャの流儀アーキテクチャ作法アーキテクチャ様式設計思想結局「ソフトウェアエンジニアリング基礎知識体系 – SWEBOK 2004- 」に従った ■ アーキテクチャスタイル ( マクロアーキテクチャパターン ) アーキテクチャスタイルとは、「一組のアーキテクチャあるいはアーキテクチャのグループがそれを満すような、一連の制約」である。したがって、アーキテクチャスタイルは、ソフトウェアシステムのハイレベルな構成 ( マクロアーキテクチャ ) を提供するメタモデルであると見なすこともできる。

リソース (1/3) REST における超重要な概念のひとつリソースの例東京の天気予報 2005年11月24日のスケジュール新花巻駅の写真 Dijkstra著 ”Go To Statement Considered Harmful” 僕の最近のブックマークリソース = 「名前」のつくありとあらゆる情報 REST ではリソースをいろいろ操作する

リソース (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

リソース (3/3) 状態リソースは状態 (state) を持つ時間や条件とともに内容が変化する可能性がある「リソースの意味」は時間や条件によらず不変である REST はリソースの representational state を transfer する東京の明日の天気予報 (Resource) Receiver 時間による変化晴れ雨 1 月 5 日 AM ( 明日は晴れそう ) 1 月 5 日 PM ( 明日は雨っぽい ) 左から右に転送ある時点におけるリソースの状態の具象的な表現

余談: リソース == オブジェクト? オブジェクトとリソースは、ちょっと違う利用 Consumer Object Interface 転送 Consumer Resource Uniform Interface http://www.markbaker.ca/2002/09/Blog/2004/10/29#2004-10-protocols REST のリソースモデリングをするときに OO の考え方が邪魔になることがある、かもしれない

質問リソースの 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 これ

URI の貼り付け == リソースの表現の取得 URI があったらブラウザのアドレス欄に入れてみるこれを REST 的に見ると URI (= リソースの識別子 ) を使ってリソースのその時点での状態の表現を HTTP GET で取得しているネットサーフィン(死語)も本質的には同じリンククリックやフォーム入力をトリガーに、リソースのある状態の表現から(別の)リソースのある状態の表現に移るどんなリソースの URI でもアドレス欄に入力(HTTP GET)できるのがすごいところ! 天気予報でも写真でも論文でも、 HTML でも PNG でも SWF でもなぜどんなリソースでも取得できるのか? リソースを操作するインターフェースが統一されているから

統一インターフェース (Uniform interface) REST を構成する超重要なスタイルの一つ HTML を取得するのが GET_HTML で、PDF を取得するのが GET_PDF だったら、今の Web はどうなっていたでしょう? 統一されるのはコンポーネント間のインターフェースブラウザ | プロクシ | リバースプロクシ | サーバリソースを識別する統一的な識別子の存在 URI 全てのリソースに適用できる洗練されたオペレーション (CRUD) GET リソースの取得 (Retrieve) PUT リソースの更新 (Update) DELETE リソースの削除 (Delete) POST リソースの作成 (Create …だけではない) 注意: この四つは特に重要。でも四つに限定しているわけではない

リンクをたどる -- ハイパーメディア A.html のリンクをクリックして B.html へ移動 A というリソースの表現から B というリソースの表現へ移動クライアントのアプリケーションの状態が A から B になるリソース同士は単純に URI と HTTP ( リンク ) で結びついている実はこれはすごいこと中央リンク管理サーバやローカルリンク管理が必要ない URI さえあれば HTTP でリソースを操作できるので、アプリケーション連携がとても簡単いわゆる疎結合の実現拡張性もあるよ！

ステートレス重要ステートレス = 状態なしメッセージ間のコミュニケーション状態がない前のリクエストで ×× だったから、次のリクエストには○○で答える、という実装にしないですむサーバ側でセッション管理しなくてよい計算機リソースを解放できるので、スケーラビリティが向上ステートレスであるためには、リクエストメッセージは自己記述的である必要がある Host ヘッダ、キャッシュ情報、認証情報、などクッキーや url-rewriting でのセッション管理は NG

目次はじめにアーキテクチャスタイル REST の概要例による REST ( と SOAP の違い ) の説明 REST アーキテクチャスタイルまとめ

REST で Web サービス Atom Publishing Protocol っぽい例による Blog 編集リソースモデルエントリ (/entry/*): 各記事 GET 記事の取得 PUT 記事の更新 DELETE 記事の削除エントリリスト (/entlylist): 記事一覧 GET 一覧の取得 POST 新記事の作成 /entrylist 日記一覧 /entry/0 REST 入門 /entry/1 てゆーか… /entry/2 ツイてる ! /entry/3 晩ご飯は…

エントリ一覧の取得 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 する ) と…

エントリの取得 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> REST は … </content> </entry>

エントリの更新 HTTP PUT HTTP/1.1 204 No Content PUT /entry/0 HTTP/1.1 Host: example.com Content-Type: application/atom+xml X-WSSE: UsernameToken… <entry> <title>REST 入門 </title> <content> REST とは … </content> </entry>

エントリの削除 HTTP DELETE HTTP/1.1 204 No Content DELETE /entry/0 HTTP/1.1 Host: example.com X-WSSE: UsernameToken…

エントリの新規作成 HTTP POST HTTP/1.1 201 Created Location: http://example.com/entry/5 POST /entrylsit HTTP/1.1 Host: example.com Content-Type: application/atom+xml X-WSSE: UsernameToken… <entry> <title>REST 入門 </title> <content> REST とは … </content> </entry> 新規作成されたリソースの URI

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);

SOAP の場合 startSession POST /servlet/blogservice HTTP/1.1 Host: example.com Content-Type: application/soap+xml <s:Envelope> <s:Body> <m: startSession > <username>yohei</username> <passwd>hogehoge</passwd> </m: startSession > </s:Body> </s:Envelope> HTTP/1.1 200 OK Content-Type: application/soap+xml <s:Envelope> <s:Body> <m:startSessionResponse> <sid> 123 </sid> </m:startSessionResponse> </s:Body> </s:Envelope> セッション ID

SOAP の場合 getEntryList POST /servlet/blogservice HTTP/1.1 Host: example.com Content-Type: application/soap+xml <s:Envelope> <s:Body> <m: getEntryList > <sid>123</sid> </m: getEntryList > </s:Body> </s:Envelope> HTTP/1.1 200 OK Content-Type: application/soap+xml <s:Envelope> <s:Body> <m:getEntryListResponse> <entryList> <entry><eid> 1 </eid>…<entry> <entry><eid> 2 </eid>…</entry> </entryList> </m:getEntryListResponse> </s:Body> </s:Envelope> エントリ ID セッション ID

SOAP の場合 getEntry POST /servlet/blogservice HTTP/1.1 Host: example.com Content-Type: application/soap+xml <s:Envelope> <s:Body> <m: getEntry > <sid>123</sid> <eid> 1 </eid> </m: getEntry > </s:Body> </s:Envelope> HTTP/1.1 200 OK Content-Type: application/soap+xml <s:Envelope> <s:Body> <m:getEntryResponse> <entry> <title>REST 入門 </entry> <content>…</content> </entryList> </m:getEntryResponse> </s:Body> </s:Envelope> エントリ ID

SOAP の場合 putEntry POST /servlet/blogservice HTTP/1.1 Host: example.com Content-Type: application/soap+xml <s:Envelope> <s:Body> <m: putEntry > <sid>123</sid> <eid>1</eid> <entry> <title>REST 入門 </title> <content>…</content> </entry> </m: putEntry > </s:Body> </s:Envelope> HTTP/1.1 200 OK Content-Type: application/soap+xml <s:Envelope> <s:Body> <m:putEntryResponse /> </s:Body> </s:Envelope>

SOAP の場合 deleteEntry POST /servlet/blogservice HTTP/1.1 Host: example.com Content-Type: application/soap+xml <s:Envelope> <s:Body> <m: deleteEntry > <sid>123</sid> <eid>1</eid> </m: deleteEntry > </s:Body> </s:Envelope> HTTP/1.1 200 OK Content-Type: application/soap+xml <s:Envelope> <s:Body> <m:deleteEntryResponse /> </s:Body> </s:Envelope>

SOAP の場合 postEntry POST /servlet/blogservice HTTP/1.1 Host: example.com Content-Type: application/soap+xml <s:Envelope> <s:Body> <m: postEntry > <sid>123</sid> <entry> <title>REST 入門 </title> <content>…</content> </entry> </m: postEntry > </s:Body> </s:Envelope> HTTP/1.1 200 OK Content-Type: application/soap+xml <s:Envelope> <s:Body> <m:postEntryResponse> <eid>5</eid> </m:postEntryResponse> </s:Body> </s:Envelope>

REST (APP) と SOAP REST URI 1 URI 2 URI 3 entrylist entry entry HTTP GET HTTP GET HTTP PUT URI 1 End point HTTP POST HTTP POST HTTP POST getEntryList() getEntry(id) putEntry(entry) SOAP

REST と SOAP の違い SOAP では Web の世界 (HTTP/URI) と Web サービス世界が分かれている ×SOAP は全部 HTTP POST を使っている ×SOAP はサービスごとの個別インターフェースがある ×SOAP メッセージには URI ( リンク ) が入ってない ×SOAP は HTTP をトランスポートプロトコルとして使うなぜ Web と Web サービスで世界を分けるのがだめなのかキャッシュ、階層化によるスケーラビリティ、プロクシによるアクセスコントロール、・・・詳しくは各アーキテクチャスタイルで

Client-Server (CS) ネットワークシステムで一番有名なスタイル二つのコンポーネントサーバ: クライアントからのリクエストを待ちながらサービスを提供クライアント: サービスにリクエストを投げ、レスポンスを受け取る制約: ユーザインターフェースとデータストレージの分離特徴 ○マルチプラットフォーム ○スケーラビリティ、サーバコンポーネントの単純化 server client

Client- Stateless -Server (CSS) ステートレス: サーバでセッション状態を持たない制約: リクエストには処理に必要な全ての情報を含む特徴 ○可視性: 一つのリクエストだけモニタリングすればよい ○信頼性: 部分的な失敗から回復 (最初からやり直さなくていい) ○スケーラビリティ: リソースをすぐに解放できる ×認証情報などを繰り返し送ることによるパフォーマンスの減少 server client client client

Client- Cache -Stateless-Server (C$SS) キャッシュ: 同じリクエストは再利用する制約: レスポンスがキャッシュ可能かどうかラベル付け (Cache-Control, Expires, …)。キャッシュ可能なら、クライアント側で保持特徴 ○サーバ、クライアントの対話を減らせる->パフォーマンス向上 ×信頼性の低下 (情報が更新されないケース) server client client client $ $

Uniform -Client-Cache-Stateless-Server (UC$SS) 統一インターフェース: REST を最も特徴付けるスタイル制約: コンポーネント間のインターフェースを固定特徴 ○アーキテクチャがシンプルに ○可視性の向上 ○クライアント/サーバ実装の独立性向上 ×情報粒度によってはトレードオフが発生＄＄＄サーバ内の実装を隠蔽

Uniform- Layered -Client-Cache-Stateless-Server (ULC$SS) 階層化システム: システムを複数階層に分割制約: システムの知識を単一階層に限る特徴 ○コンポーネントの単純化 (他レイヤは知らなくてすむ) ○ 中間子の配置 (プロクシやロードバランサなど) ○レガシーシステムの封じ込め ×ネットワークオーバーヘッドによる待ち時間の増加＄＄ $ $ レガシーシステムプロクシゲートウェイ＄＄＄

REST = Uniform-Layered- Code-on-Demand -Client-Cache-Stateless-Server (ULCODC$SS) コードオンデマンド: クライアント側でコードをダウンロードして実行 (Flash, JavaScript) 実は REST では COD はオプション特徴 ○クライアントを拡張できる ×可視性の低下＄＄ $ $ ＄＄＄

ネットワークシステムのアーキテクチャスタイル CS CSS C$SS LC$SS LCODC$SS REST Data-flow Style Replication Style Peer-to-Peer Style Hierarchical Style Mobile Code Style PF UPF RR $ LS LCS RS RDA VM REV COD MA EBI C2 DO BDO U

ネットワークシステムのアーキテクチャスタイル Data-flow 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-Cache-Stateless-Server (LC$SS) Remote Session (RS) Remote Data Access (RDA) Mobile Code Style Virtual Machine (VM) Remote Evaluation (REV) Code on Demand (COD) Layered-Code-on-Demand-Client-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)

まとめ REST は WWW のアーキテクチャスタイル REST を知らずして Web 2.0 を語ることなかれ REST ではリソースが大切 REST を構成する各制約の意味をきちんと把握しようスペックだけみてても駄目アーキテクチャスタイル重要ソフトウェア技術者の基本的スキルとなる

REST 入門

More Related Content

What's hot

Viewers also liked

Similar to REST 入門

More from Yohei Yamamoto

REST 入門