Your SlideShare is downloading. ×
RESTfulとは
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

RESTfulとは

22,228

Published on

昔、社内勉強会でRESTについて発表した時に作った資料です。PCのファイル整理してたら発掘されたので、内容をちょっと修正してアップしました。 …

昔、社内勉強会でRESTについて発表した時に作った資料です。PCのファイル整理してたら発掘されたので、内容をちょっと修正してアップしました。

『Webを支える技術 - HTTP、URI、HTML、そしてREST』 をベースにしたお話です。

Published in: Technology
0 Comments
61 Likes
Statistics
Notes

  • Be the first to comment

Show More
No Downloads
Views
Total Views
22,228
On Slideshare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
168
Comments
0
Likes
61
Embeds 0
No embeds
Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • ・RESTという命名は、コンピューター関係の用語でよくみられるこじつけ気味の命名（HTTP、PHPとかもそう）
    　「リソースの状態」（Resources State）の「表現」（REpresentational ）
    ・アーキテクチャスタイル
    　様式、作法、流儀の意
  • ・XMLではなくJSONなどで返ってくるのもあり
  • Yahoo!APIを使ったサンプル
    　キーフレーズ抽出
    　http://beer:7731/Keyphrase/
    　「パラメータを指定して特定のURLにHTTPでアクセスすると、XMLで記述されたメッセージが返ってくるようなシステム」
  • スケーラビリティとは
    　コンピュータシステムの持つ拡張性。
    　システムの利用者や負荷の増大に応じて、柔軟に性能や機能を向上させられることを意味する。
    　また、同じソフトウェアで小規模なシステムから大規模なシステムまで同じように構築できることを言うこともある。
  • CRUDとは
    　Create（生成）、Read（読み取り）、Update（更新）、Delete（削除）
    　ほとんどのコンピューターが持つ機能機能のこと
    プロトコル
    　通信規約
    　ネットワークを介してコンピュータが通信を行う上での約束事
  • URI を静的なものにする必要がある。
    そうすれば、リソースが変更された場合、またはサービスの実装が変更された場合にも、リンクは同じまま。
    こうすることでブックマークを付けられるようになる。
    また URI にエンコードされたリソース同士の関係が、それらのリソースが保存されている場所でのリソースの表現方法に依存しないようにすることも重要。
  • 「LoginServlet」
    Java→ファイル名の先頭を大文字にする
    Perl、Ruby→小文字
  • 「.do」はStrutsというWebアプリケーションワークフレームの拡張子
  • Ajaxの発展で、任意のメソッドを発行できるようになっている

    • Transcript

    • 1. 2012年4月27日
    • 2.  RESTとは  RESTfulとは  RESTのメリット  どのような考え？  おわりに
    • 3.  REpresentational State Transfer の略 Web のアーキテクチャスタイル（設計思想）のひとつ
    • 4.  我々が作る Web サービスや WebAPI は、 Web を 構成する一部である  Web の一部である以上、 Web の設計思想である REST の制約に従うことで、より良くなる
    • 5.  パラメータを指定  特定の URL に HTTP でアクセス  XMLで記述されたメッセージが返ってくる
    • 6.  Google で検索
    • 7.  検索結果が返ってきます
    • 8.  URL には色々なパラメータが入っています  https://www.google.co.jp/#hl=ja&output=s earch&sclient=psy- ab&q=REST&oq=REST&aq=f&aqi=g4&aql= &gs_nf=1&gs_l=hp.3..0l4.42102.42561.0.4 2952.4.4.0.0.0.0.78.281.4.4.0.8a54l8SEXF8 &pbx=1&bav=on.2,or.r_gc.r_pw.r_qf.,cf.osb &fp=1324bf9456410054&biw=1124&bih= 769
    • 9.  同じ URL やパラメータの組み合わせからは、常に同 じ結果が返されることが期待される  システムの状態やセッションに依存しない
    • 10.  Yahoo!API の仕様（キーフレーズ抽出） パラメータ 値 説明 appid string アプリケーションID sentence string 解析対象のテキスト output string レスポンス形式（xml 、JSON、PHP Serialize） フィールド 説明 ResultSet キーフレーズ抽出結果のすべて Result キーフレーズ抽出結果の一組 Keyphrase キーフレーズ Score キーフレーズの重要度
    • 11.  このような呼び出しインターフェースのことを RESTful API という
    • 12.  REST の規約に従った、 REST らしい Web サービス システムのこと  RESTful な Web サービス ◦ Yahoo! ◦ Google ◦ facebook ◦ twitter
    • 13.  アプリケーション中のリソースが、 URI で示せる アドレス欄に入力すれば、そのリソースを参照できる  ステートレスにすることで、スケーラビリティが向上 将来想定されるシステム規模の増大に対応可能な設計 REST の一番のメリットとされる部分です
    • 14.  統一インターフェース ◦ シンプルで一貫性のある設計 ◦ リソースへの操作は CRUD の４種類という制約 メソッドを限定することにより プロトコルがシンプルに保たれる
    • 15.  標準的なデータフォーマット（ XML や JSON ）を扱う ことで、他システムとの連携が容易になる  REST に基づいた Web アプリでは、インタフェースが 固定されている為、互換性の問題が発生しない
    • 16.  リソース指向  統一インターフェース  ステートレス
    • 17.  Web 上に存在する全ての情報はリソースである  リソースは識別子（URI）を持つ  URI を用いることで、プログラムはリソースが表現する 情報にアクセスできる  ディレクトリ構造に似た URI を定義
    • 18.  例） ◦ 東京の天気予報 http://weather.yahoo.co.jp/weather/jp/13/4410.html ◦ ITmediaのニュース記事 http://plusd.itmedia.co.jp/mobile/articles/1204/25/news046.ht ml ◦ 東陽町駅の写真 http://search-1.sakura.ne.jp/sblo_files/search- 1/image/CIMG0201.JPG ◦ REST入門 http://yohei-y.blogspot.jp/2005/04/rest_23.html
    • 19.  リソースの状態 時間や条件とともに変化する可能性がある  リソースの意味 時間や条件が変化しても不変である なるべく永続的にアクセスできるようにすべき
    • 20.  プログラミング言語依存の拡張子やパスを含めない （.pl,rb,do,jspなど）  実装依存のパス名を使用しない （cgi-bin,servletなど） 特定の実装言語に依存した文字列を URI に含めると、 その言語を変更した途端に、その URI は使えなくなってしまう http://example.jp/cgi-bin/login.pl http://example.jp/servlet/LoginServlet
    • 21.  メソッド名やセッション ID を含めない showPage のメソッド名を変更すると、 URI も変わってしまう セッション ID はログインのたびに変わるため、ログインしな おすと URI も変わってしまう http://example.jp/Login.do?action=showPage http://example.jp/home.jsp?jsessionid=123456789
    • 22.  リソースを表現する名詞であること あるリソースを取得するのか更新するのかは、 URI で指定す るのではなく、適用する HTTP メソッドで決める URI と HTTP メソッドの関係は、名詞と動詞の関係になる したがって URI は、名詞となるよう設計するべき http://example.jp/sample/people/123
    • 23.  URI がシンプルであれば、ユーザビリティが高まる 例）ログインページ 複雑な URI シンプルな URI http://example.jp/servlet/LoginServlet http://example.jp/login
    • 24.  文字数が少ない 文字数は web 以外のメディアに URI を記載するのに重要  覚えるのが簡単 長い URL 、大文字小文字の混ざった URL は間違えやすい  開発者ではない一般の人にも使いやすい 「 servlet 」など、 一般の人には馴染みのない単語は 「 server 」などと、勘違いしてしまうケースもある
    • 25. REST はプロトコルから、できるだけ多くの「アプリケー ション規約」を排除することが狙い
    • 26.  URI で指し示されるリソースに、GET や POST などの HTTP メソッドを適用する  HTTP1.1 では、 GET や POST など、8個のメソッド だけが定義されている
    • 27.  代表的な HTTP のメソッドとその役割 メソッド 役割 GET リソースの取得（読み込み） POST リソースの新規作成 PUT 既存リソースの更新 DELETE リソースの削除
    • 28.  一番良く利用されるのは、 GET と POST HTMLのフォームで指定出来るメソッドが、この２つだけに制 限されているため  GET でのアクセスはリソースの内容に影響を与えない  新しい URI を作成するときだけ POST を使用する ◦ 子リソースの作成 ◦ リソースへのデータ追加
    • 29.  全ての Web システムで URI と HTTP メソッドという 同じインターフェースを利用する  このスタイルのことを、統一インターフェースと呼ぶ
    • 30.  リクエストには、処理に必要なすべての情報を含む ステートフルとは違い、自己完結型である  サーバ資源をすぐに解放できるため、利用者や負荷 の増大に応じて、性能や機能を向上させられる
    • 31.  ステートフルの例 客(クライアント)、店員(サーバ) 店員: いらっしゃいませ。○○バーガーへようこそ 客: ハンバーガーセットをお願いします 店員: サイドメニューは何になさいますか? 客: ポテトで 店員: ドリンクは何になさいますか? 客: コーラで 店員: +50円でドリンクをLサイズにできますがいかがですか? 客: Mでいいです 店員: 以上でよろしいですか? 客: はい 店員: かしこまりました
    • 32.  ファーストフード店の店員であれば、ステートフルな実 装が当たり前ですね  次にステートレスなやりとりを見てみましょう
    • 33.  ステートレスの例 客(クライアント)、店員(サーバ) 店員: いらっしゃいませ。○○バーガーへようこそ 客: ハンバーガーセットをお願いします 店員: サイドメニューは何になさいますか? 客: ハンバーガーセットをポテトでお願いします 店員: ドリンクは何になさいますか? 客: ハンバーガーセットをポテトとコーラでお願いします 店員: +50円でドリンクをLサイズにできますがいかがですか? 客: ハンバーガーセットをポテトとコーラ(M)でお願いします 店員: 以上でよろしいですか? 客: ハンバーガーセットをポテトとコーラ(M)でお願いします。以上で 店員: かしこまりました
    • 34.  ステートフルなやりとりは簡潔 サーバがクライアントのそれまでの注文を覚えている  ステートレスなやりとりは冗長 クライアントは毎回すべての注文を繰り返している
    • 35. ステートフルな方が良い？
    • 36.  Webサーバの場合は、スケーラビリティの問題がある  店員(サーバ)が一人の客(クライアント)をずっと相手 にしていると、その間別の客に対応することができな い  店が混んできたら(アクセスが集中したら)、店員を増 員して(Webサーバを増設して)対応する
    • 37.  普通の店舗では、ひとつのレジで一人の店員がずっ と同じ客を受け付ける  Web の場合は複数の Web サーバ(比較的少数)で 複数のクライアント(比較的多数)を同時に受け付ける  ステートレスであれば、各要求で別々の店員(サーバ) が、客(クライアント)の注文(リクエスト)に応答(レスポ ンス)することが可能になる
    • 38.  ステートレスの例２ 客(クライアント)、店員１～６(サーバ) 店員１: いらっしゃいませ。○○バーガーへようこそ 客: ハンバーガーセットをお願いします 店員２: サイドメニューは何になさいますか? 客: ハンバーガーセットをポテトでお願いします 店員３: ドリンクは何になさいますか? 客: ハンバーガーセットをポテトとコーラでお願いします 店員４: +50円でドリンクをLサイズにできますがいかがですか? 客: ハンバーガーセットをポテトとコーラ(M)でお願いします 店員５: 以上でよろしいですか? 客: ハンバーガーセットをポテトとコーラ(M)でお願いします。以上 店員６: かしこまりました
    • 39.  ステートレスなサーバは、アプリケーション状態を覚え る必要がないので、サーバ側のシステムは単純にな る  クライアントはどのサーバにリクエストを送ってもかま わない →必要な情報は全てリクエストに含まれているから
    • 40. ステートレスな方が良い？
    • 41.  パフォーマンスの低下 ◦ 送信するデータ量が多くなる ◦ 認証など、サーバに負荷がかかる処理をくり返す  通信エラーへの対処が重要 ◦ レスポンスがうまく受け取れなかった場合、リクエストを２重に 受け付けてしまう ◦ ステートフルであれば、すでにリクエストを受け付けたことを 覚えている
    • 42. 結局どっちが良いの？
    • 43.  どちらもメリット、デメリットがあるので、要件に応じて 設計することが重要
    • 44.  URI 設計の重要性 REST に基づいた URI 設計により、ユーザビリティは高まる  Web アプリ設計の技法として ステートレスな設計は、煩雑なシステムになりにくい  Web サービスを作る際の設計指針として 他システムと簡単に連携でき、大規模なサービスの拡張にも役立つ  標準的な API の提供 RESTful API を公開することで、標準的なデータフォーマットを使 い、多様なアプリケーションを提供することができる
    • 45.  山本 陽平 著 『Webを支える技術 - HTTP、URI、HTML、そして REST』 技術評論社、2010年  RESTful Web サービスの基本 http://www.ibm.com/developerworks/jp/webservices/library/ws-restful/  REST 入門 http://yohei-y.blogspot.jp/2005/04/rest_23.html  RESTful Web Services より良いWebインタフェースの 構築と分散型システム連携 http://labo.mamezou.com/special/sp_013/

    ×