Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo
2012年4月27日
 RESTとは
 RESTfulとは
 RESTのメリット
 どのような考え?
 おわりに
RESTfulとは
 REpresentational State Transfer の略
Web のアーキテクチャスタイル(設計思想)のひとつ
 我々が作る Web サービスや WebAPI は、 Web を
構成する一部である
 Web の一部である以上、 Web の設計思想である
REST の制約に従うことで、より良くなる
 パラメータを指定
 特定の URL に HTTP でアクセス
 XMLで記述されたメッセージが返ってくる
 Google で検索
 検索結果が返ってきます
 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
 同じ URL やパラメータの組み合わせからは、常に同
じ結果が返されることが期待される
 システムの状態やセッションに依存しない
 Yahoo!API の仕様(キーフレーズ抽出)
パラメータ 値 説明
appid string アプリケーションID
sentence string 解析対象のテキスト
output string レスポンス形式(xml 、JSON、PHP Serialize)
フィールド 説明
ResultSet キーフレーズ抽出結果のすべて
Result キーフレーズ抽出結果の一組
Keyphrase キーフレーズ
Score キーフレーズの重要度
 このような呼び出しインターフェースのことを
RESTful API という
RESTfulとは
 REST の規約に従った、 REST らしい Web サービス
システムのこと
 RESTful な Web サービス
◦ Yahoo!
◦ Google
◦ facebook
◦ twitter
RESTfulとは
 アプリケーション中のリソースが、 URI で示せる
アドレス欄に入力すれば、そのリソースを参照できる
 ステートレスにすることで、スケーラビリティが向上
将来想定されるシステム規模の増大に対応可能な設計
REST の一番のメリットとされる部分です
 統一インターフェース
◦ シンプルで一貫性のある設計
◦ リソースへの操作は CRUD の4種類という制約
メソッドを限定することにより
プロトコルがシンプルに保たれる
 標準的なデータフォーマット( XML や JSON )を扱う
ことで、他システムとの連携が容易になる
 REST に基づいた Web アプリでは、インタフェースが
固定されている為、互換性の問題が発生しない
RESTfulとは
 リソース指向
 統一インターフェース
 ステートレス
RESTfulとは
 Web 上に存在する全ての情報はリソースである
 リソースは識別子(URI)を持つ
 URI を用いることで、プログラムはリソースが表現する
情報にアクセスできる
 ディレクトリ構造に似た URI を定義
 例)
◦ 東京の天気予報
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
 リソースの状態
時間や条件とともに変化する可能性がある
 リソースの意味
時間や条件が変化しても不変である
なるべく永続的にアクセスできるようにすべき
 プログラミング言語依存の拡張子やパスを含めない
(.pl,rb,do,jspなど)
 実装依存のパス名を使用しない
(cgi-bin,servletなど)
特定の実装言語に依存した文字列を URI に含めると、
その言語を変更した途端に、その URI は使えなくなってしまう
http://example.jp/cgi-bin/login.pl
http://example.jp/servlet/LoginServlet
 メソッド名やセッション ID を含めない
showPage のメソッド名を変更すると、 URI も変わってしまう
セッション ID はログインのたびに変わるため、ログインしな
おすと URI も変わってしまう
http://example.jp/Login.do?action=showPage
http://example.jp/home.jsp?jsessionid=123456789
 リソースを表現する名詞であること
あるリソースを取得するのか更新するのかは、 URI で指定す
るのではなく、適用する HTTP メソッドで決める
URI と HTTP メソッドの関係は、名詞と動詞の関係になる
したがって URI は、名詞となるよう設計するべき
http://example.jp/sample/people/123
 URI がシンプルであれば、ユーザビリティが高まる
例)ログインページ
複雑な URI
シンプルな URI
http://example.jp/servlet/LoginServlet
http://example.jp/login
 文字数が少ない
文字数は web 以外のメディアに URI を記載するのに重要
 覚えるのが簡単
長い URL 、大文字小文字の混ざった URL は間違えやすい
 開発者ではない一般の人にも使いやすい
「 servlet 」など、 一般の人には馴染みのない単語は
「 server 」などと、勘違いしてしまうケースもある
REST はプロトコルから、できるだけ多くの「アプリケー
ション規約」を排除することが狙い
RESTfulとは
 URI で指し示されるリソースに、GET や POST などの
HTTP メソッドを適用する
 HTTP1.1 では、 GET や POST など、8個のメソッド
だけが定義されている
 代表的な HTTP のメソッドとその役割
メソッド 役割
GET リソースの取得(読み込み)
POST リソースの新規作成
PUT 既存リソースの更新
DELETE リソースの削除
 一番良く利用されるのは、 GET と POST
HTMLのフォームで指定出来るメソッドが、この2つだけに制
限されているため
 GET でのアクセスはリソースの内容に影響を与えない
 新しい URI を作成するときだけ POST を使用する
◦ 子リソースの作成
◦ リソースへのデータ追加
 全ての Web システムで URI と HTTP メソッドという
同じインターフェースを利用する
 このスタイルのことを、統一インターフェースと呼ぶ
RESTfulとは
 リクエストには、処理に必要なすべての情報を含む
ステートフルとは違い、自己完結型である
 サーバ資源をすぐに解放できるため、利用者や負荷
の増大に応じて、性能や機能を向上させられる
 ステートフルの例
客(クライアント)、店員(サーバ)
店員: いらっしゃいませ。○○バーガーへようこそ
客: ハンバーガーセットをお願いします
店員: サイドメニューは何になさいますか?
客: ポテトで
店員: ドリンクは何になさいますか?
客: コーラで
店員: +50円でドリンクをLサイズにできますがいかがですか?
客: Mでいいです
店員: 以上でよろしいですか?
客: はい
店員: かしこまりました
 ファーストフード店の店員であれば、ステートフルな実
装が当たり前ですね
 次にステートレスなやりとりを見てみましょう
 ステートレスの例
客(クライアント)、店員(サーバ)
店員: いらっしゃいませ。○○バーガーへようこそ
客: ハンバーガーセットをお願いします
店員: サイドメニューは何になさいますか?
客: ハンバーガーセットをポテトでお願いします
店員: ドリンクは何になさいますか?
客: ハンバーガーセットをポテトとコーラでお願いします
店員: +50円でドリンクをLサイズにできますがいかがですか?
客: ハンバーガーセットをポテトとコーラ(M)でお願いします
店員: 以上でよろしいですか?
客: ハンバーガーセットをポテトとコーラ(M)でお願いします。以上で
店員: かしこまりました
 ステートフルなやりとりは簡潔
サーバがクライアントのそれまでの注文を覚えている
 ステートレスなやりとりは冗長
クライアントは毎回すべての注文を繰り返している
ステートフルな方が良い?
 Webサーバの場合は、スケーラビリティの問題がある
 店員(サーバ)が一人の客(クライアント)をずっと相手
にしていると、その間別の客に対応することができな
い
 店が混んできたら(アクセスが集中したら)、店員を増
員して(Webサーバを増設して)対応する
 普通の店舗では、ひとつのレジで一人の店員がずっ
と同じ客を受け付ける
 Web の場合は複数の Web サーバ(比較的少数)で
複数のクライアント(比較的多数)を同時に受け付ける
 ステートレスであれば、各要求で別々の店員(サーバ)
が、客(クライアント)の注文(リクエスト)に応答(レスポ
ンス)することが可能になる
 ステートレスの例2
客(クライアント)、店員1~6(サーバ)
店員1: いらっしゃいませ。○○バーガーへようこそ
客: ハンバーガーセットをお願いします
店員2: サイドメニューは何になさいますか?
客: ハンバーガーセットをポテトでお願いします
店員3: ドリンクは何になさいますか?
客: ハンバーガーセットをポテトとコーラでお願いします
店員4: +50円でドリンクをLサイズにできますがいかがですか?
客: ハンバーガーセットをポテトとコーラ(M)でお願いします
店員5: 以上でよろしいですか?
客: ハンバーガーセットをポテトとコーラ(M)でお願いします。以上
店員6: かしこまりました
 ステートレスなサーバは、アプリケーション状態を覚え
る必要がないので、サーバ側のシステムは単純にな
る
 クライアントはどのサーバにリクエストを送ってもかま
わない
→必要な情報は全てリクエストに含まれているから
ステートレスな方が良い?
 パフォーマンスの低下
◦ 送信するデータ量が多くなる
◦ 認証など、サーバに負荷がかかる処理をくり返す
 通信エラーへの対処が重要
◦ レスポンスがうまく受け取れなかった場合、リクエストを2重に
受け付けてしまう
◦ ステートフルであれば、すでにリクエストを受け付けたことを
覚えている
結局どっちが良いの?
 どちらもメリット、デメリットがあるので、要件に応じて
設計することが重要
RESTfulとは
 URI 設計の重要性
REST に基づいた URI 設計により、ユーザビリティは高まる
 Web アプリ設計の技法として
ステートレスな設計は、煩雑なシステムになりにくい
 Web サービスを作る際の設計指針として
他システムと簡単に連携でき、大規模なサービスの拡張にも役立つ
 標準的な API の提供
RESTful API を公開することで、標準的なデータフォーマットを使
い、多様なアプリケーションを提供することができる
 山本 陽平 著
『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/

More Related Content

RESTfulとは

Editor's Notes

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