REST 入門

10,348 views

Published on

Published in: Technology
0 Comments
8 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
10,348
On SlideShare
0
From Embeds
0
Number of Embeds
79
Actions
Shares
0
Downloads
210
Comments
0
Likes
8
Embeds 0
No embeds

No notes for slide
  • 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. おわり

    ×