Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

REST 入門

11,096 views

Published on

Published in: Technology
  • Be the first to comment

REST 入門

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

×