わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
RESTFul Webサービス
猪股健太郎
@matarillo
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
アジェンダ
• RESTの説明
– RESTとは
– RESTの原則
– RESTful WebサービスとHTTP
• .NETでの実装
– WCF
– WCF REST Starter Kit
– RestCake
– ASP.NET MVC
– OpenRasta
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
質問1
• この本のどちらかを持ってる人
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
質問2
• 以下のどれかを受講した人
Tech・Ed Japan 2009T2-310 「WCF で実現する SOA、REST」
(MS 松崎さん)
Tech・Ed Japan 2010T6-312 「WCF 4 における新機能のポイント」
(アークウェイ奥田さん・飯田さん)
Tech・Ed Japan 2010T4-303 「Open Data Protocol (Odata) と
WCF Data Services によるサービスの作成」(MS 井上さん)
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
第1部 RESTの説明
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
REST
• 2000年
• ロイ・フィールディングの博士論文
– なぜWebはこんなに普及したのか?
– なぜWebは大規模でもうまく動くのか?
– Webの設計原則とは?
それを“REST”と呼ぶことにする。
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
REST ○×
• 設計原則
• アーキテクチャスタイル
• 通信プロトコルではない
• 仕様ではない
• 標準ではない
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
言葉の定義:Webサービス
• 広い意味でのWebサービス
– Webで提供されるサービス
•検索エンジン、Webメール、顧客管理SaaS
• 中ぐらいの意味でのWebサービス
– プログラムが呼び出すWeb API
• Twitter API、Amazon Web サービス、Bing API
• 狭い意味でのWebサービス
– SOAPおよびWS-*を使ったインターフェース
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
言葉の定義:Webサービス
• 広い意味でのWebサービス
– Webで提供されるサービス
•検索エンジン、Webメール、顧客管理SaaS
• 中ぐらいの意味でのWebサービス
– プログラムが呼び出すWeb API
• Twitter API、Amazon Web サービス、Bing API
• 狭い意味でのWebサービス
– SOAPおよびWS-*を使ったインターフェース
今日はこの意味です。
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
今日の言葉の定義
• RESTful WebサービスとはREST アーキテクチャスタイルを採用しているWebサービスのこと。
– 「RESTっぽいWebサービス」
– 「REST」という言葉の使われ方は「オブジェクト指向」という言葉の使われ方にも似ている。
– RESTを構成する原則は複数ある。
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
RESTの原則
• RESTアーキテクチャスタイルの原則を大きく2つに分類する
– 分散システムとしての構造の原則
•クライアント・サーバー型の発展形
– 分散システムが扱う情報の原則
•リソース
• HATEOAS
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
RESTの原則(構造編)
• クライアント・サーバー
クライアント サーバー
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
RESTの原則(構造編)
• クライアント・サーバー&ステートレス
クライアント ステートレスサーバー
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
RESTの原則(構造編)
• クライアント・サーバー&ステートレス&キャッシュ
クライアント ステートレスサーバー
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
RESTの原則(構造編)
• クライアント・サーバー&ステートレス&キャッシュ&統一インターフェース
クライアント ステートレスサーバー
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
RESTの原則(構造編)
• クライアント・サーバー&ステートレス&キャッシュ&統一インターフェース&階層化システム
クライアント ステートレスサーバー
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
RESTの原則(構造編)
• クライアント・サーバー&ステートレス&キャッシュ&統一インターフェース&階層化システム&コード・オン・デマンド(任意)
クライアント ステートレスサーバー
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
RESTの原則(情報編)
• リソースとは?
– 名前がつけられる情報すべて
– 名前がつけられる=他と区別できる
– 抽象的
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
RESTの原則(情報編)
• リソース
「東京の今日の天気」
「わんくま同盟のメンバリスト」
「藍澤光の壁紙(WP7用)」
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
RESTの原則(情報編)
• リソース&アドレス
「東京の今日の天気」http://weather.yahoo.co.jp/weather/jp/13/4410.html
「わんくま同盟のメンバリスト」http://www.wankuma.com/member/
「藍澤光の壁紙(WP7用)」http://www.microsoft.com/taiwan/silverlight/images/480X800_f.jpg
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
RESTの原則(情報編)
• リソース&アドレス&表現
「東京の今日の天気」http://weather.yahoo.co.jp/weather/jp/13/4410.htmlhtml
「わんくま同盟のメンバリスト」http://www.wankuma.com/member/html
「藍澤光の壁紙(WP7用)」http://www.microsoft.com/taiwan/silverlight/images/480X800_f.jpgjpeg
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
RESTの原則(情報編)
• リソース&アドレス&表現&メタデータ
「東京の今日の天気」http://weather.yahoo.co.jp/weather/jp/13/4410.htmlhtmlピンポイント天気へのリンクなど
「わんくま同盟のメンバリスト」http://www.wankuma.com/member/html
「藍澤光の壁紙(WP7用)」http://www.microsoft.com/taiwan/silverlight/images/480X800_f.jpgjpeg最終更新日時:10/08/2010 18:31:46
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
RESTの原則(情報編)
• HATEOAS
– Hypermedia as the Engine of Application State
– アプリケーションの状態を表現する機構としてハイパーメディアを使う
– アプリケーションの状態遷移にハイパーリンクを活用する
•商品一覧のXMLに「次の100件」へのリンクをいれておく
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
ここまでのまとめ
• RESTはWebの設計原則を分析したもの
• RESTはアーキテクチャスタイル
• 大きく2つに分類できる
– 分散システムとしての構造の原則
•クライアント・サーバー型の発展形
– 分散システムが扱う情報の原則
•リソース
• HATEOAS
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
RESTという単語
• Representational State Transfer– リソースの現在の状態を
– 表現したものを
– 転送する
「Webで使われるプロトコルは
HTTP (HyperText Transfer Protocol)だけど、これって
ハイパーテキスト以外にも便利に使えるよね?」
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
RESTとHTTP
抽象概念 具体的な例
REST Web
リソースハイパーメディア
アドレス URI
統一インターフェース
HTTP
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
RESTful Webサービス
抽象概念 具体的な例
REST Webサービス
リソース (リソース)
アドレス URI
統一インターフェース
HTTP
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
統一インターフェースとしてのHTTP
• HTTPとは
– リソースのアドレスをURLで
– リソースのメタデータをHTTPヘッダで
– リソースの表現をHTTPボディで
– リソースに対する操作をHTTPメソッドで
• 表すプロトコル
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
HTTPの4大メソッド
• GET– リソースの表現を取得する
• POST– 既存のリソースに関連する何かを追加する
– 既存のリソースにデータを渡して何かをする
• DELETE– 既存のリソースを削除する
• PUT– URLを指定して新しいリソースを作成する
– 既存のリソースを変更する
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
HTTPのベストプラクティス
• GET/DELETE/PUTを「べき等」にする
• 可能な限り標準のメソッドを使う
• POSTメソッドを濫用しない
– HTTPボディにリソースのアドレスを含めない
– HTTPボディにリソースの操作を含めない
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
RESTではないもの
• RPCスタイルのアーキテクチャ
– HTTPボディにリソースのアドレスを含める
– HTTPボディにリソースの操作を含める
– 結果的に、POSTばかりを使う
<?xml version="1.0"?><methodCall>
<methodName>examples.getStateName</methodName><params>
<param><value><i4>40</i4></value>
</param></params>
</methodCall>
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
RPCスタイルは「間違っている」か?
• そうとは言えない
• RPCスタイルのほうが向いている処理もある
• ただ、RESTの方がWebの利点を享受できる
– 普及性やスケーラビリティ
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
RESTful Webサービスの設計
1. サービスが扱うデータ集合を特定する
2. データ集合をリソースに分ける
3. リソースにURIをつける
4. リソースに対する操作を決める
5. 送受信する表現を決める
6. リソース間のリンクを設計する
7. リソースの状態遷移を検討する
8. エラーを検討する
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
RESTful Webサービスのベストプラクティス
• コレクションリソース
– http://edtter.com/chack/status• GET……リソース一覧の取得 (R)
• POST……新規リソースの追加 (C)– 作成されたリソースのURIをレスポンスに含める
• 個別リソース
– http://edtter.com/chack/status/123456• GET……個別リソースの取得 (R)
• PUT……個別リソースの更新 (U)
• DELETE……個別リソースの削除 (D)
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
RESTful Webサービスのベストプラクティス
• Atom出版プロトコル (AtomPub)
– IETFが標準化→ RFC 5023
– Web リソースを出版・編集する
•コレクション: 全体的に、あるいは部分的に検索され得るリソースの集合
•サービス: コレクションの発見と記述
•編集: リソースの生成、編集、削除
– リソース一覧のページングにも対応
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
第2部 .NETでの実装
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
WCF REST
• .NET Framweork 3.5以降
• WebServiceHostFactoryクラス
• WCFの面倒なconfigが不要
• クライアントの「サービス参照」不可
<%@ ServiceHost Language="C#" Debug="true"Service="WcfRestService1.Service1"CodeBehind="Service1.svc.cs"Factory="System.ServiceModel.Activation.WebServiceHostFactory" %>
Service1.svc
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
WCF REST
• HTTP GETは[WebGet]カスタム属性、それ以外は[WebInvoke]カスタム属性
• リクエストやレスポンスはPOX / JSON / バイトストリームの三択
• HttpContextの代わりに
WebOperationContext– “201 Created”と“404 Not Found”にはショートカットあり
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
WCF REST
• Visual Studio ギャラリーからテンプレートをダウンロード可能(VS2010用)
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
WCF RESTのgood/bad
• いい点
– わりと自由にできる
• つらい点
– カスタムシリアライズ
– HATEOAS
– URLに「○○.svc」が含まれる
• .NET4からはルーティングと統合できる
– クライアントの実装
– 実はWCF
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
WCF REST Starter Kit
• WCF REST Starter Kit
– http://aspnet.codeplex.com/wikipage?title=WCF%20REST
– Preview 2 (2009/3/10) はVS2008 SP1用
– サーバ側
• POX、単一要素、コレクション、Atom Feed、AtomPub
– クライアント側
• HttpClient
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
WCF REST Starter Kitのgood/bad
• いい点
– 型にはまった実装は楽
• CRUDとHTTPメソッドのマッピングとか
• POX/JSON対応サービスとか
• ヘルプページとか
• 例外処理とか
– HttpClientが手軽
– OSS
• つらい点
– 自由がきかない
– VS2010未サポート (Preview2)
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
RestCake
• RestCake
– http://rest.codeplex.com/
– http://restcake.net/Overview.aspx
• いい点
– WCFじゃない
– でも似たような感じで作れる
– 罠が少ない
• JSONとか、匿名型とか、循環参照とか……
– OSS
• つらい点
– 自己責任
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
ASP.NET MVC
• ASP.NET MVCをWebサービスに使う
– Viewが「リソースの表現」になるだけ。
• いい点
– リソース表現が自由
– WCFじゃない
– OSS
– 赤シャツ印
• つらい点
– GET/POST/PUT/DELETE/HEADだけ対応
– 細かい道具がそろってない
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
OpenRasta
• OpenRasta
– http://openrasta.com/
– RESTful Webアプリケーション/Webサービス
– http://live.visitmix.com/MIX10/Sessions/EX19
• いい点
– ASP.NET MVCに近い形で、より強力にRESTをサポート
– .NET Framework 2.0以降で動作
– リソース表現が自由
– 属性いらない
• つらい点
– ???
REST Architecture Solution Targeting Asp.net
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
質疑応答タイム
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
補足:トランザクションの実現
• http://developer.cybozu.co.jp/kazuho/2010/04/rest-re-web-a6d.html– トランザクションの開始は POST を使ったトランザク
ションリソースの生成
– トランザクション開始後は POST ではなく PUT を使い、クライアントがリクエスト ID を指定することで、ネットワーク障害への耐性を確保
– トランザクションのコミットも再送可能じゃないと困るので PUT
– コミットの返り値を確認してからトランザクションリソースをDELETE
わんくま同盟東京勉強会 #52
Wankuma Developer Deep Dive
参考情報
• REST in Windows Communication Foundation (WCF)
– http://msdn.microsoft.com/wcf/rest
• A Guide to Designing and Building RESTfulWeb Services with WCF 3.5
– http://msdn.microsoft.com/en-us/library/dd203052.aspx