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

What's hot (20)

Viewers also liked (6)

Similar to RESTfulとは (18)

More from 星影月夜 (7)

RESTfulとは

Editor's Notes

RESTfulとは

More Related Content

What's hot (20)

Viewers also liked (6)

Similar to RESTfulとは (18)

More from 星影 月夜 (7)

RESTfulとは

Editor's Notes

More from 星影月夜 (7)