RESTfulとは

 RESTとは
 RESTfulとは
 RESTのメリット
 どのような考え？
 おわりに

 REpresentational State Transfer の略
Web のアーキテクチャスタイル（設計思想）のひとつ

 我々が作る Web サービスや WebAPI は、 Web を
構成する一部である
 Web の一部である以上、 Web の設計思想である
REST の制約に従うことで、より良くなる

 パラメータを指定
 特定の URL に HTTP でアクセス
 XMLで記述されたメッセージが返ってくる

 検索結果が返ってきます

 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 という

 REST の規約に従った、 REST らしい Web サービス
システムのこと
 RESTful な Web サービス
◦ Yahoo!
◦ Google
◦ facebook
◦ twitter

 アプリケーション中のリソースが、 URI で示せる
アドレス欄に入力すれば、そのリソースを参照できる
 ステートレスにすることで、スケーラビリティが向上
将来想定されるシステム規模の増大に対応可能な設計
REST の一番のメリットとされる部分です

 統一インターフェース
◦ シンプルで一貫性のある設計
◦ リソースへの操作は CRUD の４種類という制約
メソッドを限定することにより
プロトコルがシンプルに保たれる

 標準的なデータフォーマット（ XML や JSON ）を扱う
ことで、他システムとの連携が容易になる
 REST に基づいた Web アプリでは、インタフェースが
固定されている為、互換性の問題が発生しない

 リソース指向
 統一インターフェース
 ステートレス

 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 はプロトコルから、できるだけ多くの「アプリケー
ション規約」を排除することが狙い

 URI で指し示されるリソースに、GET や POST などの
HTTP メソッドを適用する
 HTTP1.1 では、 GET や POST など、8個のメソッド
だけが定義されている

 代表的な HTTP のメソッドとその役割
メソッド役割
GET リソースの取得（読み込み）
POST リソースの新規作成
PUT 既存リソースの更新
DELETE リソースの削除

 一番良く利用されるのは、 GET と POST
HTMLのフォームで指定出来るメソッドが、この２つだけに制
限されているため
 GET でのアクセスはリソースの内容に影響を与えない
 新しい URI を作成するときだけ POST を使用する
◦ 子リソースの作成
◦ リソースへのデータ追加

 全ての Web システムで URI と HTTP メソッドという
同じインターフェースを利用する
 このスタイルのことを、統一インターフェースと呼ぶ

 リクエストには、処理に必要なすべての情報を含む
ステートフルとは違い、自己完結型である
 サーバ資源をすぐに解放できるため、利用者や負荷
の増大に応じて、性能や機能を向上させられる

 ステートフルの例
客(クライアント)、店員(サーバ)
店員: いらっしゃいませ。○○バーガーへようこそ
客: ハンバーガーセットをお願いします
店員: サイドメニューは何になさいますか?
客: ポテトで
店員: ドリンクは何になさいますか?
客: コーラで
店員: +50円でドリンクをLサイズにできますがいかがですか?
客: Mでいいです
店員: 以上でよろしいですか?
客: はい
店員: かしこまりました

 ファーストフード店の店員であれば、ステートフルな実
装が当たり前ですね
 次にステートレスなやりとりを見てみましょう

 ステートレスの例
客(クライアント)、店員(サーバ)
店員: いらっしゃいませ。○○バーガーへようこそ
店員: サイドメニューは何になさいますか?
客: ハンバーガーセットをポテトでお願いします
店員: ドリンクは何になさいますか?
客: ハンバーガーセットをポテトとコーラでお願いします
店員: +50円でドリンクをLサイズにできますがいかがですか?
客: ハンバーガーセットをポテトとコーラ(M)でお願いします
店員: 以上でよろしいですか?
客: ハンバーガーセットをポテトとコーラ(M)でお願いします。以上で
店員: かしこまりました

 ステートフルなやりとりは簡潔
サーバがクライアントのそれまでの注文を覚えている
 ステートレスなやりとりは冗長
クライアントは毎回すべての注文を繰り返している

ステートフルな方が良い？

 Webサーバの場合は、スケーラビリティの問題がある
 店員(サーバ)が一人の客(クライアント)をずっと相手
にしていると、その間別の客に対応することができな
い
 店が混んできたら(アクセスが集中したら)、店員を増
員して(Webサーバを増設して)対応する

 普通の店舗では、ひとつのレジで一人の店員がずっ
と同じ客を受け付ける
 Web の場合は複数の Web サーバ(比較的少数)で
複数のクライアント(比較的多数)を同時に受け付ける
 ステートレスであれば、各要求で別々の店員(サーバ)
が、客(クライアント)の注文(リクエスト)に応答(レスポ
ンス)することが可能になる

 ステートレスの例２
客(クライアント)、店員１～６(サーバ)
店員１: いらっしゃいませ。○○バーガーへようこそ
店員２: サイドメニューは何になさいますか?
客: ハンバーガーセットをポテトでお願いします
店員３: ドリンクは何になさいますか?
客: ハンバーガーセットをポテトとコーラでお願いします
店員４: +50円でドリンクをLサイズにできますがいかがですか?
客: ハンバーガーセットをポテトとコーラ(M)でお願いします
店員５: 以上でよろしいですか?
客: ハンバーガーセットをポテトとコーラ(M)でお願いします。以上
店員６: かしこまりました

 ステートレスなサーバは、アプリケーション状態を覚え
る必要がないので、サーバ側のシステムは単純にな
る
 クライアントはどのサーバにリクエストを送ってもかま
わない
→必要な情報は全てリクエストに含まれているから

ステートレスな方が良い？

 パフォーマンスの低下
◦ 送信するデータ量が多くなる
◦ 認証など、サーバに負荷がかかる処理をくり返す
 通信エラーへの対処が重要
◦ レスポンスがうまく受け取れなかった場合、リクエストを２重に
受け付けてしまう
◦ ステートフルであれば、すでにリクエストを受け付けたことを
覚えている

結局どっちが良いの？

 どちらもメリット、デメリットがあるので、要件に応じて
設計することが重要

 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/

RESTfulとは

More Related Content

RESTfulとは

Editor's Notes