2008年に導入されたAzureストレージはその後いろいろな改良や機能追加があり、現在7つのバージョンのREST APIが提供されています。今回のアナウンスはその中の古いいくつかのバージョンの削除に関しての情報です。
詳細は上記リンクを見てもらうとして、ざっくり意訳というか適当に日本語にしてみました。ちゃんと知りたい人は原文みましょう。（自己責任で）
背景：ストレージサービスのバージョニングについて
バージョン管理ってなんですか？
AzureストレージはREST APIを使用してアクセスします。最初のAPIは2008年にリリースされました。
その後Microsoftはサービスをよりよく改善させるために追加や変更を行ってきました。その際、既存のアプリケーションが動作しなくなることを回避するためにAPIにバージョン管理を行いました。
サービスの変更などは既存のアプリケーションを壊す可能性があるので、変更を加えるときは新しいバージョンのAPIを追加しオプトインで明示的に使用するようにしました。このため既存のアプリケーションは新しいバージョンについて影響を受けることはありません。
ストレージのREST API呼び出しは一般的には以下のいずれかの方法で使用するバージョンを指定します。
- api-version クエリパラメーター
- sv と x-ms-version が指定されていない場合、また2014以降のバージョンを指定した場合にストレージに対するすべての呼び出しに指定できます。この api-version パラメーターで使用されるサービスのバージョンが決まります。
- x-ms-version リクエストヘッダー
- 共有キー認証を使用して呼び出す際に要求されるリクエストヘッダーです。x-ms-version リクエストヘッダーは要求を解釈し、どのバージョンのREST APIをクライアントへの応答として返すかを指定します。
- SAS version ヘッダー
- バージョン2012と2013で共有アクセス署名（SAS）トークンのSVパラメーターで指定されたプロトコルバージョンです。バージョン2014以降ではapi-versionクエリパラメーターが指定されていない場合、SVパラメーターはプロトコルのバージョンを指します。
- DefaultServiceVersion
- バージョン指定しないリクエスト（パブリックBLOBへのアクセスの際など）の際に使用するAPIをバージョンをBLOBのSetServicePropertiesを使うことで指定することができます
- 既定
- パブリックBLOBへのアクセスやDefaultServiceVersionが指定されていない場合、サービスの既定値が使用されます。SetContainerACLが使用されない場合、2009が使用されます（当初は2008だった）※SetContainerACLのために使われたバージョンに関係なく）
完全なルールについてはこちら参照（MSDN）
クライアントライブラリについて
多くのユーザーはアプリケーションを開発する際にマイクロソフトが提供するストレージクライアントライブラリを使用します。これらのクライアントライブラリはそれぞれ本質的に特定のREST APIのバージョンにバインドされています。
また、これはMicrosoftのAzure PowerShell CmdletsやAzCopyにも適用されます。
ストレージエミュレーターはリリースされた時点で提供されているすべてのREST APIのバージョンをサポートします。
何がかわるの？
バージョン管理に関する考え方は変わりません。マイクロソフトは既存のアプリケーションを壊すかもしれない変更を加えるたびに新しいREST APIのバージョンを導入していきます。しかし、マイクロソフトは今回ストレージサービスの初期にリリースされたいくつかのバージョンを削除します。
削除の詳細
どのバージョンが削除されるの？
2015年8月1日に、2012-02-12より古いバージョンが削除されます。
削除されるバージョン
- Version 2008 (GA時のバージョン）
- Version 2009-04-14(GA時のバージョン）
- Version 2009-07-17(GA時のバージョン）
- Version 2009-09-19(GA時のバージョン）
- Version 2011-08-18
以下のバージョンは削除の影響を受けず、サポートされます。
いつ削除されますか？
削除予定の5つのバージョンは2015年8月1日に削除されます。
これらのバージョンが削除された時に何が起きますか？
以下のような変更が発生します。
明示的なバージョン指定を要求
x-ms-versionリクエストヘッダに削除されたバージョンのいずれかを指定した場合、無効なバージョンヘッダーがついた要求の際と同様にHTTP400（不正な要求）ステータスコードが返され失敗します。
SVパラメーターが無いSASリクエスト
2012-02-12より古いバージョンのSASリクエストはSASトークンのsvパラメータでバージョンを指定していませんでした。これらの要求のSASトークンパラメーターは2009-07-17のREST APIとして解釈されていました。
今回、2012-02-12より古いバージョン（2009-07-17を含む）が削除されるので（x-ms-versionが指定されているかどうかにかかわらず）これらのリクエストは失敗し、HTTP400（Bad Reqeust）ステータスコードを受信します。
継続して動作させるにはSASリクエストの際にsvパラメータを使用してバージョンを指定する必要があります。（少なくとも2014-02-14を指定することが推奨されます）
明示的なバージョン指定のない匿名リクエストと既定のバージョン
もしSetBlobServiceProperties（REST API）が2012-02-12以上のバージョンを既定のバージョンとして設定されている場合はこのバージョンセットが使用されます。
既定のバージョンセットが未設定の場合、要求はバージョンに依存しないと仮定し今後は2014-02-14で応答を開始します。バージョン指定されていない要求は、新しいバージョンがリリースされた場合にアプリケーションが動作することを保証しません。ベストプラクティスは常に最新のバージョンを使用し続けることです。
既定のサービスバージョンに削除されるバージョンを設定している場合、その要求は明示的にバージョン管理をしているとみなされHTTP400（Bad Request）ステータスコードで失敗します。
既定のサービスバージョンがサポートされているバージョンに設定されている場合はそのバージョンが使用されます。
明示的なバージョンが指定されていないSharedKey/SharedKeyLite要求
ストレージアカウントの共有キーを使って署名されたリクエストで、もしx-ms-versionヘッダーまたはapi-versionクエリパラメーター（2014-02-14以降でサポート）を使用して指定されていない場合、要求がHTTP400（Bad Request）で失敗します。
補足：これはストレージサービスに対するすべての要求が明示的にバージョン管理されていることを保証するためのベストプラクティスです。バージョン2014-02-14以降、要求がカスタムヘッダーでバージョンを明示的に指定することができなくても、api-versionクエリパラメーターを使うことで、クライアントがバージョン指定することができます。詳細はMSDNを参照ください。
サポートされている最も古いバージョン/ライブラリ/SDK
| 言語 | 2012-02-12以降のバージョンをサポートしている最小バージョン |
| .NET | 2.0 (Azure SDK 2.1に含まれています |
| Java | 0.3 |
| C++ | すべて |
| Windows Phone | すべて |
| WinRT | すべて |
| Android | すべて |
| PHP | 現在リリースされているSDKは2012-02-12をサポートしていません。（アップデートはcoming soon.） |
| Node.js | 現在のリリースバージョンは2012-02-12をサポートしています |
| Ruby | 現在のリリースバージョンは2012-02-12をサポートしています |
| Python | 現在のリリースバージョンは2012-02-12をサポートしています |
| PowerShell | すべて |
| CLI | 現在のリリースバージョンは2012-02-12をサポートしています |
※PHPだけちょっとしんどいですね
どうすればいいですか？
古いバージョンが削除された後も正常に動作させるには次のことを行う必要があります。
アプリケーションで使用されているバージョンを確認する
最初にすることはアプリケーションで使用されているREST APIのバージョンを確認し判断することです。
アプリケーションがコントロール下にあり、Azureストレージへの呼び出しのすべてを知っている自身がある場合は上記のコンポーネントをチェックすることで確認することができます。また独自コードでストレージ呼び出しなどをしている場合はコードをすべて検査してチェックします。
使用しているコンポーネントのバージョンなどがわからない場合は、ストレージアカウントのログを有効化して、要求を記録することができます。ログには要求のバージョン等が含まれています（詳細）。
以下の例は匿名でGetBlobリクエストを行った際のログです。この例では2009-09-19のバージョンが使用されています。
1.0;2011-08-09T18:52:40.9241789Z;GetBlob;AnonymousSuccess;200;18;10;anonymous;;myaccount;blob;”https:// myaccount.blob.core.windows.net/thumbnails/lake.jpg?timeout=30000″;”/myaccount/thumbnails/lake.jpg”;a84aa705-8a85-48c5-b064-b43bd22979c3;0;123.100.2.10;2009-09-19;252;0;265;100;0;;;”0x8CE1B6EA95033D5″;Friday, 09-Aug-11 18:52:40 GMT;;;;”8/9/2011 6:52:40 PM ba98eb12-700b-4d53-9230-33a3330571fc”
何を変えればよいですか？
削除されるバージョンを使用しているログを見つけた場合、そのコンポーネントを見つけ、継続して動作できるように確認する必要があります。（バージョンを指定していない要求については、暗黙のバージョンで動作します（上述参照））
適切な手順で使用するバージョンを変更してください。一般的には次の2つの手順のどちらかが使われます。
- 通常、ライブラリやツールの新しいバージョンに移行することでリクエストに使用されるバージョンを変更します。可能な場合、他の改善や修正も含めるために最新のバージョンを取得して移行します。
- 動作するかどうか古いバージョンが削除される前に既定のサービスバージョンをサポートされるバージョンにセットしてください。これはバージョンを明示しないリクエストや匿名のリクエストにだけ当てはまります。
新しいバージョンにアプリケーションを移行する場合、更新したあと正しくアプリケーションが動作することを確実とするために現在動作しているサービスと変更点のリストを確認し徹底的にテストする必要があります。
REST APIのバージョンのアップデートには構文の変更（Syntactic breaks：リクエストに対して異なる応答を受信する場合があります）や意味の変更（Semantic breaks：リクエストに対して意味が異なる似たような応答を受信する場合があります）の両方が含まれるので注意してください。
移行後の検証
移行後は以前の（古い）バージョンのリクエストが無いかログを検証する必要があります。これはアプリケーションが削除される古いバージョンのREST APIを使用していないか知ることができる最も確実な方法です。たとえば1日1回だけ実行されるようなスケジュールされたタスクなど滅多に発生しないタスク/ワークロードの場合を想定して十分に長い期間にわたってログを確認してください。
まとめ
2015年8月1日に古いバージョンのREST APIが削除されることに備え、今からアプリケーションのアップグレードを開始することをオススメします。
ブチザッキ 