GAE開発の落とし穴
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
News
ブックマークされました！
ブックマークがエラーになりました。もう一度お願いします。
RESTfulなウェブサービスのバージョン管理戦略
作者 Dilip Krishnan , 翻訳者 徳武 聡 投稿日 2010年3月9日
この記事でStu Charlton氏はRESTfulなサービスのバージョン管理のさまざまな選択肢を挙げている。しかし、氏は前置きとして次のように書いている。“これらの例は説明するにはトリッキーな概念で、この話題について何か小さな本を書こうとは思いません。”氏はバージョン管理の問題をふたつのタイプに分けている。ひとつはデータのバージョン管理で、リソースそのものバージョン管理を支援し、リソースの状態の変化を追跡することで、あるリソースの状態を明らかにできる。もうひとつは言語のバージョン管理で、言語とはプロトコルそのものことで、言い換えれば表現のことだ。
URIのバージョン管理は[…]リソースそのものは不変で新しい状態のリソースを作成するときの選択肢の設計することです(これはデータベースで時系列のデータを扱う方法に似ています)。
一方、言語の拡張またはバージョン管理はリソースの状態ではなくデータの表現の仕方を変える方法のことです。
Stu Charlton氏はW3C TAGでDavid Orchard氏が作成したバージョン互換性戦略のドラフトに依拠している。この戦略が明らかにするのは、前方互換性や後方互換性、また互換性を維持しない変更の複雑さだ。“言語の拡張については考えなければならない点がある”、とした上で氏は下記のことを強調する。
ルール #1: 前方そして/または後方の互換性を維持する方法で言語を拡張するのが望ましい。非互換であることを表すのにバージョン識別子を使うのは最終手段にする。
氏は下記のような表でこのドラフトの内容をまとめている。
| 消費者 | 生産者 | |
|---|---|---|
| 後方互換 |
|
|
| 前方互換 |
|
|
| 非互換 |
|
|
氏は続けて、上の表で使っているバージョン通知、置き換え、サイドバイサイド、バージョン識別子という言葉を定義し、さまざまな互換性のシナリオの中で生産者と消費者がどうやって“言語”が不明の要素を扱うかについて説明している。ここで氏はバージョン識別子を提供するいろいろな戦略を検討して、これらの戦略を適用する際の優先度について議論している。
メディアタイプコンテンツの中にバージョン識別子を含める
この方法はありふれています。例えばHTML DOCTYPEであり、XMLNSもこの方法に使えます。またPDFドキュメントにバージョン識別子を含む方法もそうです。[…] この方法が実現できるのはウェブで扱われるメディアタイプのほとんどが長い間使われてきて、相応に成功を収めているからです。しかし、これらのフォーマットは前方互換を考慮して、長期の視点に立って設計されていることに注意する必要があります。
MIMEの中にバージョン識別子を含める
[…]この方法の利点はURI空間に影響を与えることなくサイドバイサイドのバージョン管理を実現できることです。[…しかし…]この方法だとハイパーメディアが扱いにくくなり、ウェブアーキテクチャ(HTTP そして/または URI)以外のレイヤに影響が出てしまいがちです。例えば、application/vnd.mytype;version=2のような表現になります。
URIの中にバージョン識別子を含める
リソースの意味自体が変わったらURIを新しくするのは当然のことです。なので、リソースがその表現とともに変化すれば、新しいURIが生まれます。[…] 例えば、http://example.com/data/v1/po/123のようなものです。
また、ブックマークの問題もあります。この問題は、データベースシステムの"外部キー"の問題と似ています。リレーショナルデータベースについて知っているひとなら、主キーは絶対に変更すべきでないということを知っていると思います。これは外部キーを更新するのが大変だからです。
氏が勧めるのは、Subbu Allamaraju氏が書いたRESTful Web Services Cookbookの13章を読んでこのテーマについての理解を深めることだ。そして、自身の記事を次のような要約で締めくくっている。
- 言語と互換性のための置き換え方法は、柔軟で前方と後方に互換性を持ようにするのが望ましい。Note the W3C TAGのバージョン識別子についての見解を参照すること。
- URIの中にバージョン識別子を入れる場合はよく考えいること。今までのかっこいいURIを変更しないように。
- サイドバイサイドでバージョン管理をする場合は、バージョンの新しい/古いが判別できる情報をメディアの一部かリンクに含めること。参照の更新は消費者がキャッシュをリフレッシュしたときでよい。古い言語と結びついているURIには恒久的なリダイレクトを設定する。
- リソースの意味が変わったらURIのバージョンを変えること。ただし、リンクで古いバージョンか新しいバージョンかわかるようにすることが消費者側に対する礼儀。
氏の記事はRESTfulなサービスのバージョン管理問題 への解決策を構成する要素をまとめあげようとしている。しかし、これらの戦略についてはどの選択肢が正しいのかについて議論が続いている。
関連情報
【豆蔵】「オブジェクト指向を現場で活かすリファクタリング入門」新規講座キャンペーン中
【ネクストスケープ】.NET、C#のアプリケーション開発者募集
No comments
スレッド表示 返信