1. 2012年4月27日

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

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

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

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

7.  Google で検索

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

9.  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

10.  同じ URL やパラメータの組み合わせからは、常に同
じ結果が返されることが期待される
 システムの状態やセッションに依存しない

11.  Yahoo!API の仕様（キーフレーズ抽出）
パラメータ 値 説明
appid string アプリケーションID
sentence string 解析対象のテキスト
output string レスポンス形式（xml 、JSON、PHP Serialize）
フィールド 説明
ResultSet キーフレーズ抽出結果のすべて
Result キーフレーズ抽出結果の一組
Keyphrase キーフレーズ
Score キーフレーズの重要度

12.  このような呼び出しインターフェースのことを
RESTful API という

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

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

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

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

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

22.  Web 上に存在する全ての情報はリソースである
 リソースは識別子（URI）を持つ
 URI を用いることで、プログラムはリソースが表現する
情報にアクセスできる
 ディレクトリ構造に似た URI を定義

23.  例）
◦ 東京の天気予報
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

24.  リソースの状態
時間や条件とともに変化する可能性がある
 リソースの意味
時間や条件が変化しても不変である
なるべく永続的にアクセスできるようにすべき

25.  プログラミング言語依存の拡張子やパスを含めない
（.pl,rb,do,jspなど）
 実装依存のパス名を使用しない
（cgi-bin,servletなど）
特定の実装言語に依存した文字列を URI に含めると、
その言語を変更した途端に、その URI は使えなくなってしまう
http://example.jp/cgi-bin/login.pl
http://example.jp/servlet/LoginServlet

26.  メソッド名やセッション ID を含めない
showPage のメソッド名を変更すると、 URI も変わってしまう
セッション ID はログインのたびに変わるため、ログインしな
おすと URI も変わってしまう
http://example.jp/Login.do?action=showPage
http://example.jp/home.jsp?jsessionid=123456789

27.  リソースを表現する名詞であること
あるリソースを取得するのか更新するのかは、 URI で指定す
るのではなく、適用する HTTP メソッドで決める
URI と HTTP メソッドの関係は、名詞と動詞の関係になる
したがって URI は、名詞となるよう設計するべき
http://example.jp/sample/people/123

28.  URI がシンプルであれば、ユーザビリティが高まる
例）ログインページ
複雑な URI
シンプルな URI
http://example.jp/servlet/LoginServlet
http://example.jp/login

29.  文字数が少ない
文字数は web 以外のメディアに URI を記載するのに重要
 覚えるのが簡単
長い URL 、大文字小文字の混ざった URL は間違えやすい
 開発者ではない一般の人にも使いやすい
「 servlet 」など、 一般の人には馴染みのない単語は
「 server 」などと、勘違いしてしまうケースもある

30. REST はプロトコルから、できるだけ多くの「アプリケー
ション規約」を排除することが狙い

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

49. 結局どっちが良いの？

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

52.  URI 設計の重要性
REST に基づいた URI 設計により、ユーザビリティは高まる
 Web アプリ設計の技法として
ステートレスな設計は、煩雑なシステムになりにくい
 Web サービスを作る際の設計指針として
他システムと簡単に連携でき、大規模なサービスの拡張にも役立つ
 標準的な API の提供
RESTful API を公開することで、標準的なデータフォーマットを使
い、多様なアプリケーションを提供することができる

53.  山本 陽平 著
『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/