REST

第8回XML開発者の日

発表者

名字まで(合わせるために)

概要

RESTの正体

RESTはWWWのアーキテクチャスタイル

REpresentational State Transfer

REST実装例

はてなウェブサービスとRESTfulWiki

トラックバックとMT

APIとして見たトラックバックとMT

RSSとWebDAVとAtom

RSSとAtom Syndication、WebDAVとAtom Public Publishingを比較

AJAXがRESTに与える影響

AJAXとRESTとの関係

パネルディスカッション

RESTの正体

RESTはXML over HTTPではなく、WWWのアーキテクチャスタイル。

アーキテクチャスタイル(マクロアーキテクチャパターン)

例)P2P、MVC、パイプ&フィルタ、クライアントサーバ

各スタイルは『特徴的な制約の集合から成り立つ』

RESTにおける概念

リソース

  • 名前のつくありとあらゆる情報
  • 全てのリソースは識別子を持つ(URI)
  • リソースは状態を持つ
    • 時間や条件とともに内容が変化する
    • リソースの意味は変わらない

RESTはリソースのrepresentational StateをTransferする。

Uniform Interface

Webブラウザからあるリソースを取得する事を考える。

  1. URIをアドレス欄に貼付ける
  2. 「移動ボタン」を押すなどしてリソースを取得する

URIを使ってHTTP GETでリソースのその時の状態の表現を取得する。

Webブラウザの場合、アドレス欄にURLを指定するという統一されたインターフェースを利用してリソースを取得する事が出来る。

条件

  • 統一されるのはコンポーネント間のインターフェース
  • リソースを識別する統一的な識別子の存在

HTTPの場合

CRUD(Create-Read-Update-Delete)

  • GET
  • PUT
  • DELETE
  • POST

リンクを辿る

リソース同士は単純にURIHTTPで結びつく。

URIがあればHTTPでリソースとアプリケーションとの連携が簡単になる』→疎結合

ステートレス

サーバ側でセッション管理の必要が無いため、サーバリソースをすぐに解放できる。→スケーラビリティ

リクエストメッセージは自己記述的である。

cookieやurl-rewritingを利用するとRESTではない。

REST(AtomPP)とSOAPとの比較

RESTはUniform Interfaceであるため、インターフェースと目的とがURIで直接結びつく。一方、SOAPはインターフェースと目的とがまとまって結びつく。

URIによってそれぞれの目的が独立する場合、クライアントとサーバの間にプロキシなどを挿む事が出来る。それぞれがまとめられる場合、目的ごとにこれを行う事は出来ない。

SOAP

Web(URI/HTTP)とサービスが分離

  • 全てPOST
  • メッセージごとのインターフェース
  • メッセージにURI(リンク)が入っていない
    • リンクとして辿る事が出来ない
  • HTTPをトランスポートプロトコルとして利用
    • 単純に『送る』ために使う

RESTのアーキテクチャスタイル

CS(Client-Server)

制約

UIとデータストレージの分離

特徴
  • マルチプラットフォーム
  • スケーラビリティ
  • サーバコンポーネントの単純化

CSS(Client-Stateless-Server)

制約

サーバー側はステートレスである

特徴

リクエストには処理に必要な全ての情報が含まれる。

  • ○可視性
  • ○信頼性
  • ○スケーラビリティ
  • ×パフォーマンス低下

C$SS(Client-Cache-Stateless-Server)

制約

同じキャッシュは再利用

特徴
  • レスポンスがキャッシュ可能かラベル付け
  • サーバとクライアントの対話を減らす

Uniform-C$SS

制約

コンポーネント間のインターフェースを固定

特徴
  • ○アーキテクチャがシンプル
  • ○可視性が向上
  • ○CS実装の独立性
  • ×情報粒度によってはトレードオフが発生する

U-Layered-C$SS

制約

システムの知識を1階層に限る

特徴
  • ○コンポーネントの単純化
  • ○中間子の配置(プロクシ、ロードバランサ)
  • ○レガシーシステムの隠蔽
  • ×ネットワークオーバーヘッドによる待ち時間
UL-Code on Demand-C$SS =

クライアントでコードをダウンロードして実行(Flash, JS)

※RESTではCODはオプション

特徴
  • ○クライアントを拡張できる
  • ×可視性の低下(クライアントとサーバの間)

まとめ

ネットワークのアーキテクチャスタイル

  • RESTはWWWのアーキテクチャスタイル
  • RESTでは(URIが意味する)リソースが重要
  • RESTを構成する各制約の意味を把握(スペックだけを見ても駄目)
  • アーキテクチャスタイルは重要(ソフトウェア技術者の標準スキル?)

RESTの実装例

APIを公開する意味

ウェブサービス(Web based Service)のターゲットには2種類がある。一般サービスのターゲットであるエンドユーザと、XMLウェブサービスAPIのターゲットになるデベロッパやGeekな人たち。

技術革新を伴うサービスの利用者層推移はハイテクオタクやビジョン先行と行った層が先行する。ビジョン先行層と価格品質重視層との間にはハイテクの落とし穴(Chasm)があり、ここを見落とすと大変。

『技術革新を伴うサービスにとってGeekは重要』

データ重要

ユーザーがデータをコントロールできる事が大切。

  • インポート/エクスポート
  • フィード出力
  • フィードで過去の物もページングなどでさかのぼる事が出来る
  • APIで保存・編集・削除・取得などが出来る

はてなウェブサービス

AtomPPを採用した理由

  • 他のAPIとの相互互換性
    • はてなのためだけに開発・習得しなければならない事が減る
  • 既存ライブラリを利用できる
  • はてなとRESTとの相性が良さそう

Cool URI

奇麗なURIを心がける。

MVCフレームワークとURI

M

O/Rマッパ

V

テンプレートエンジン

C

それぞれに特徴的なアーキテクチャ

Controller

URIからクラスやメソッドへのdispatch(接続?)に規約(制約)を設ける。

制約による利点
  • URI+フレームワークでURI設計に無知でもCool URIを作る事が出来る。
  • 『Modelをリソースと見立てて、そのControllerを起動するURIを決定する』ことは自然な流れ。
  • URIから対象のクラスやメソッドが分かる
  • 結果的にRESTに近づくためREST APIと相性が良くなる

フレームワークとWebAPI

WebAPIを容易に扱える様に、そのアーキテクチャを抽象化する事が重要→標準化

AtomPP所感

RESTやAtomPPの制約が邪魔になる場合

小さなAPIを作るとき

  • URIに対して被コメント数を返す
  • 大げさ、無理矢理になら可能→どうしたらいいの?

エレメントに対応するデータが直感的でない

  • summaryがコメント?titleがタグ?
  • 結局仕様書が必要
  • 本当にこれでいいの?

サーバー側の実装が面倒→フレームワーク重要

del.icio.usでは

  • XML over HTTP
  • Basic認証+野良XML

シンプルで分かり易く、データ項目が明快である。また、小さなAPIも気にせず実装可能。ライブラリもサードパーティ製のものが用意されている(Net:Delicious/Perl)。

まとめ

  • WebAPIを公開する事には意味がある
  • REST的なAPIであればAtomPPがいい
  • URIとフレームワークは重要

こぼれ話

RESTとページングとはトレードオフの関係が発生する場合がある。

AtomPPはAtomで返すために仕様上の制約が発生し、返って邪魔になる場合がある。

はてなダイアリーでは1日の記事を1レコードとしているために、APIにしずらい。

RESTfulWiki

RESTとWikiの相性

  • リソースの名前が明快
  • ページに対して誰でもCRUD可能(認証が必要ない)

Rails

  • URIと内部処理とのマッピングが可能

トラックバックとMT

トラックバック

SixApartが定める仕様

  • 参照側から被参照リンクを要求し、被参照側にリーダーからのプッシュで掲載できる
  • ブログを中心に、wikiやニュース記事など様々な利用
  • REST-likeな実装
  • Auto-Discovery(XHTMLに埋め込む)
  • RSSへの埋め込み(Draft)
  • MetaWeblogAPI
  • AtomPP(まだ)

エンコーディング

Charsetとして宣言される(MTは未実装)。クライアント側に任せられているため、マルチバイトの場合はUTF-8がお薦め。

利用される理由

  • 被参照情報への強いニーズ
  • コンテンツホルダーの明確化
  • 実装がシンプル

Trackback SPAMの問題点

  • nofollow、moderation、blacklistで対応
  • identification/Authentication(サイトが分散した時の認証など/TypeKeyやOpenID)

Movable Type

MTの位置づけは、ブログではなく『パブリッシング・プラットフォーム』

Plugin/APIと拡張性

  • tag, filter, callback and action
  • Perl API(プラットフォームとしての位置づけ)

こぼれ話

海外ではトラックバックが実装されるブログはあまりない

MT以前に出来上がったブログはトラックバックをサポートしない

トラックバックのREST化

スタンドアロンのプロトコル化したことで、日本でこれだけ流行した

RSSとWebDAVとAtom

  • RSS2.0継承のAtom Syndication
  • うりふたつなWebDAVとAtom Publishing Protocol

データモデル

  • 階層化ストレージモデル:WebDAV
  • ハイパーリンクモデル:WWW
  • タプルスペースモデル:REST
  • Uniform Interface:REST, SQL

WebDAVの歴史

  • 1992 ウェブ誕生
  • 1993 writable webは置いてけぼり
  • 1996 ウェブオーサリングシステムの乱立
  • 1996 標準化
  • 1996 - 1998 XMLとの擦り合わせ、POST-onlyにするべきとか試行錯誤
  • 1999 RFC2518

Atomの歴史

  • 1999 RSS0.90(RDF)をNetscapeが開発
  • 1999 RSS0.91(RDFを破棄)
  • 1999 NetscapeがRSSを放棄し、Dave Warnerが引き継ぐ
  • 2000 rss-devグループがRSS1.0(RDF)を開発
  • 2000 RSS1.0に前後してUserLand版0.91と0.92がリリース
  • 2002 MetaWeblogAPIが0.92を取り込む

RDFな人は「RDFで自由拡張」、「セマンティックウェブの第1歩」を主張

DWな人は「オーバーデザインを捨てる」、「安い、早い、旨い最強」を主張

RSS2.0は名前空間に対応するも、RSS2.0の要素は名前空間に所属しないという状態に

Atomって何?

Atomは2つの性質を持つ

  • Atom Syndication(フィード)
  • Atom Publishing Protocol(ウェブリソースのCRUDプロトコル)

Atom Syndication

特徴

  • RSS2.0が30要素持つのに対して、Atomは21要素に抑えられている(使わない要素の排除)
  • 含める内容をより詳細に規定(機械に易しい)
  • 1クリック購読が可能(フィード中で流通の身元証明が可能)
  • エントリだけを流通させる事が可能(エントリ中でアグリゲーション時の身元証明が可能)
  • リソースタイプの記述が可能

問題

  • 機能的にはRSS2.3
  • RSS1.0/RSS2.0とはっきりした差が無いため、これまでに流通したデータはなかなか消えない
  • RDF/RSS/Atomの三国志

結局

Webではデータの合意が重要

Atom Publishing Protocol

特徴

  • RESTアーキテクチャに従う
  • 普通のHTTPでコンテンツを操作できる

WebDAVとの比較

WebDAVはHTTP+XML+HTTP機能拡張であるのに対し、AtomPPはHTTP+XML+HTTP用法定義。

WebDAV

階層構造のリソース構成で、各リソースに各自任意のXMLで記述できる属性がついてくる。リソースは親コレクション直下のURI。 (ファイルシステム的オペレーション)

常にリソースの名前が分からないとリソースを作る事が出来ない(クライアントがリソースのURIを知らないといけない)。

AtomPP

フラットなフィードで、再帰的操作という概念が無い。リソースはどこのURIでも許される。

純粋なWebはAtomPPのデータモデル(ハイパーリンク)。

POSTで「無名」リソースを作る事が出来る。

つまり

AtomPPはHTTPの枠内で、WebDAVはHTTPを改良したもの。

ただし、世の中にはGET/POSTのみをサポートするHTTPクライアントが存在する(J2ME, Flash)。これをSOAP経由で行うAPIセットがAtomPPに定義されていたが、途中で切り離された。現在は拡張アクセスの手段として考えられている。

結局、目的レベルでは同じである。

重要

「RESTのためにAtomがあるんじゃねぇ、データのためにRESTがあるんだ。」

REST

  • 情報の共有や交換が目的
  • 連携コストを最小にする

共有と交換

  • 共通の合意
  • 情報のVisibility+reachability(E2E principle的)
  • メタデータ、インターフェースだけの検索は偽物(フルデータよこせ)

連携コスト

  • コード界に必要な物はインターフェースとデータ(パラメータと返り値)

データの自動共通理解はHard SemWeb問題(ほとんど無理)

つまり

  • URIがプロトコル独立を保証する
  • インターフェースを隠蔽する

メリット

  • 「万能」クライアント
    • ウェブブラウザはReadonly→ReadWrite(CRUD)にしてくれる
    • データ種類×アクセス手段の数のクライアントは悪夢
  • 今あるデータは参照可能なまま

デメリット

  • 世の中の99%はGETで、残りをPOSTでやっても問題ない(POSTはセマンティック上最強)
  • RESTは実装上どうしても苦しいところがある
  • インターフェースが細粒度ではない
    • 全てがバルクアップデート
    • 名前フィールドを変えるだけでも全て更新
    • 裏のシステムが複雑になると変更検知が困難
    • 複数のアクセスが連鎖するとき必要なデータが必要以上に増える
  • データのネーミングが足を引っ張る
    • データに名前がつかなくてはならない(URI)
    • 全てのデータにabsolute URI

まとめ

  • RESTは強力だけど、実装が大変
  • RESTはスケーラビリティのためであって、RESTありきで考えてはいけない
  • データ利用をどこまで勝手にスケールさせるか(チェイン)
  • REST-friendlyな連携モデルが重要
    • データの合意をとり、ウェブに載せて繋げていく
      • XHTML
      • XML
      • マシン処理可能な物

AJAXによるRESTへの影響

AJAXはRESTfulか

そうでもあり、そうでもない。

AJAXのためのREST(REST2.0)

リソース

remixingによって、1つのURIに複数のリソースが対応する

CoD

XMLHttpRequestによってコードがコネクタとなる(1クライアントに複数のコネクタ)

ブックマーク

URIを与える場合の設計指針として

  • Server-side representation:URIを与える
  • Client-side representation:URIを与えなくても良い

AJAXとRESTと認証

Webの認証

cookieベースで、サーバー側でセッションを管理するためRESTfulじゃない。

RESTの認証

アクセスの度に認証を行うためキュリティ的な問題などがある。

RESTの限界をAJAXで対処

リソースごとに認証の必要性を考え、リソースを別々に取得する。認証が要らない場合Cache可能。

AJAXを利用した方がScalable?

認証不要な部分を認証せずに取得できる様になる。

パネルディスカッション

発表まとめ

  • REST重要
  • フレームワーク重要
  • 実装大変
  • データ(合意)重要
  • 課題あり
    • AJAXとREST
    • 認証(Atuthentication&Identification)
  • Simple & Sloppy
  • RSSはwell-formed?(IE7)

RESTと制約

  • ブラウザ以外のクライアントを対象にする場合、他のWeb Servicesに比べてRESTは緩め。
  • サーバー側でステートを持てないためにリソース粒度が大きくなる

箱庭のススメ

  • インターネットスケールでなく、限定されたところで”Web”を実現すると完全なWebができるかも(Wikiとか)
  • URIで色々繋がることが大切で、リンク重要

Webは緩やかなリンクしか出来ないため、データを密接に繋げるためにはハードなリンクが出来る空間が必要になる。

エンタープライズの状況

  • RESTは中央集権
  • ビジネスはP2P
  • トランスポートは二の次で、データの標準かが鍵
    • XML over HTTP
    • XML over SMTP

インターネットスケール

  • 基本的に合意は無い
  • データ構造はWebに合わせる
  • 更新とかはバックエンドで対応

イントラネット

  • 中央管理が大事
  • ミッションクリティカルな物にルーズな物は使えない
    • どの技術も『ルーズ→しっかり』を繰り返してるからいずれ平気になる?

データモデル

素直なデータモデルが重要で、シンプルなプラットフォームにする事が重要

Web Service

XMLスキーマがボトルネック(全てを台無しにする?)

REST効果

URIの決定など、アプリケーションの指針になる

Cool URI

SEO対策や設計ルールに良い。

SEO

GoogleのロボットはCGI実行を嫌うため、?やパラメータを持つURIを嫌がる。クライアントから動的生成を隠す事が重要。

Delphi

kylix(Linux版Delphi?)を利用して、Apacheモジュール(DSO)が開発可能(速度向上など)。

URIの表現

  • 人に分かり易い方がいいか、マシンが分かればいいのか。
  • 重要なのは、リソースに対するURIが不変(永続性がある)である事→permalink
  • tiny URIを利用して、『知っている=認証』という構図はどうか(RESTの認証問題)。
  • 永続性と可読性のトレードオフ?
  • 人向けとマシン向けの2つあると良いかも。
 
koshigoewiki/rest/第8回xml開発者の日.txt · 最終更新: 2005/11/28 21:31 by koshigoebushou
 
Creative Commons License Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki