1 / 45

REST 入門

REST 入門. 2005 年 11 月 24 日 第八回 XML 開発者の日. 株式会社リコー ソフトウェア研究開発本部 山本陽平. 目次. はじめに アーキテクチャスタイル REST の概要 例による REST ( と SOAP の違い ) の説明 REST アーキテクチャスタイル まとめ. http://d.hatena.ne.jp/Nayuta/20050727#1122477974. 自己紹介. ソフトウェア技術者、 XML guy 1975 年生まれ ( 同い年の人の例 )  経験

ivor-joyner
Télécharger la présentation

REST 入門

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 目次 • はじめに • アーキテクチャスタイル • REST の概要 • 例による REST (と SOAP の違い) の説明 • REST アーキテクチャスタイル • まとめ 2005-11-24 第八回XML開発者の日

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

  4. 村田さんの blog も し か し て 今日がその日?? 2005-11-24 第八回XML開発者の日

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

  6. 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開発者の日

  7. 目次 • はじめに • アーキテクチャスタイル • REST の概要 • 例による REST (と SOAP の違い) の説明 • REST アーキテクチャスタイル • まとめ 2005-11-24 第八回XML開発者の日

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

  9. 目次 • はじめに • アーキテクチャスタイル • REST の概要 • 例による REST (と SOAP の違い) の説明 • REST アーキテクチャスタイル • まとめ 2005-11-24 第八回XML開発者の日

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

  11. リソース (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開発者の日

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

  13. これ 質問 • リソースの 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開発者の日

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

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

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

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

  18. 目次 • はじめに • アーキテクチャスタイル • REST の概要 • 例による REST (と SOAP の違い)の説明 • REST アーキテクチャスタイル • まとめ 2005-11-24 第八回XML開発者の日

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

  20. エントリ一覧の取得 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開発者の日

  21. エントリの取得 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開発者の日

  22. エントリの更新 HTTP PUT 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> HTTP/1.1 204 No Content 2005-11-24 第八回XML開発者の日

  23. エントリの削除 HTTP DELETE DELETE /entry/0 HTTP/1.1 Host: example.com X-WSSE: UsernameToken… HTTP/1.1 204 No Content 2005-11-24 第八回XML開発者の日

  24. エントリの新規作成 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開発者の日

  25. 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開発者の日

  26. 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 2005-11-24 第八回XML開発者の日

  27. 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 2005-11-24 第八回XML開発者の日

  28. 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 2005-11-24 第八回XML開発者の日

  29. 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> 2005-11-24 第八回XML開発者の日

  30. 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> 2005-11-24 第八回XML開発者の日

  31. 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> 2005-11-24 第八回XML開発者の日

  32. REST entrylist HTTP GET URI 1 entry HTTP GET URI 2 entry HTTP PUT URI 3 SOAP HTTP POST getEntryList() End point HTTP POST getEntry(id) URI 1 putEntry(entry) HTTP POST REST (APP) と SOAP 2005-11-24 第八回XML開発者の日

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

  34. 目次 • はじめに • アーキテクチャスタイル • REST の概要 • 例による REST (と SOAP の違い) の説明 • REST アーキテクチャスタイル • まとめ 2005-11-24 第八回XML開発者の日

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

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

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

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

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

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

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

  42. 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) ネットワークシステムのアーキテクチャスタイル 2005-11-24 第八回XML開発者の日

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

  44. おわり 2005-11-24 第八回XML開発者の日

  45. 2005-11-24 第八回XML開発者の日

More Related