使ってみよう! Windows Live SDK/API

第16回 Windows Live Application Based Storage API(1)

この記事を読むのに必要な時間:およそ 4 分

本記事の対象APIは既にサポートされていません。記事は参考程度にご利用ください。

Application Based Storage API

今回からWindows Live ユーザーデータAPI群よりWindows Live Application Based Storage APIについて紹介します。このAPIは、Windows Live委任認証を利用する必要があります。委任認証については本連載の第14回15回に紹介しましたので参考にしてください。また、Application Based Storage APIは、執筆時点でのAPIバージョンはAlpha 1.0と試験的なサービスです。今後サービス内容が変更される可能性は十分にありますのでご了承ください。

さて、Application Based Storage APIを利用するとWebサイト(Webアプリケーション)から多様なデータをWindows Liveデータセンター(ストレージ)へユーザーに代わり保管することができます。扱うことのできるデータは基本的には文字列となるアプリケーションの状態や設定値が想定されているようですが、画像などバイナリデータの保管も可能です。委任認証を利用していることからわかるように、ストレージへのアクセスはユーザーの承諾を得て初めてアプリケーションからアクセスが可能になります。ストレージは一般的なファイルシステムと同様にフォルダとファイルからなる階層構造となっています。

リソースへのアクセス

データにアクセスするにはWeb上でデータを読み書きするための規格であるAtomプロトコルを利用します。このAtomプロトコルの利用もApplication Based Storage APIの特徴です。共通的な仕様を利用しているため、ほかのAtomプロトコルを利用したアプリケーションとの連携も可能です。

実際にデータへアクセスする場合、ある書式に従ったURLへHTTPのGETやPOSTメソッドによりアクセスします。そのことによってファイル一覧の取得やフォルダの作成、ファイルのダウンロード・アップロードができます。その際の認証はWindows Live 委任認証により得られた委任トークンを使用した独自の認証方法になります。

承認の要求時にはオファーとアクションを指定する必要がありました。その承認要求に指定するpsパラメータには「ApplicationStorage.ReadWrite」と指定します。Application Based Storeage APIで指定できるオファーとアクションの組み合わせはこの1種類のみです。

そして、承認要求により委任トークンを取得後にアクセスするURLの書式は次のようになります。

https://cumulus.services.live.com/@C@[LID]/AtomApplicationStorage[/リソースへのパス]

[LID]には委任認証により取得した承認トークンのlidパラメータ、つまりユーザーデータの場所を示す識別子です。URLの末尾にはリソースへのパスを指定します。具体的なアクセス方法は後ほど紹介します。

ストレージの構造と構成

先にストレージについて一般的なファイルシステムと同じ階層構造と書きましたが、Application Based Storage独特の仕様もあります。URLに指定するリソースパスを指定するためにも理解が必要になってきますので、まずはApplication Based Storage APIで扱うストレージの構造について理解しましょう。

コレクションノードとアイテムノード

Application Based Storageはコレクションノードとアイテムノードと呼ばれる大きくふたつの要素から構成されています。コレクションノードには次の種類があり、コレクションノードは複数の要素を持つことができます。わかりやすく言えばフォルダですね。

  • RootFolders
  • Items
  • DocumentStreams
  • PhotoStreams

各コレクションの種類の内容はひとまず後にして、続いてアイテムノードには次の種類があります。

  • Folder
  • Document
  • DocumnetStream
  • Photo
  • PhotoStream

アイテムノードにもFolderと名のつくものがあり少しややこしいですが、コレクションノードは複数の要素を表すもので、アイテムノードは単体のオブジェクトを表すものと考えてください。

ストレージの最上位の階層にはRootFoldersと呼ばれる特別なフォルダ群があります。そのフォルダより下の階層にあるフォルダに格納されているフォルダとファイル群はItemsと呼びます。

フォルダに格納できるもの、一般的にいうフォルダとファイルは、フォルダを表すFolder、文書ファイルを表すDocumentと画像を表すPhotoがあります。アップロードできる文書と画像の種類は何でもよいというわけでなく、サポートされているものは限られています。

DocumentStream(s)、PhotoStream(s)はここで扱いませんので割愛します。

RootFolders

ストレージの最上位階層にあるRootFoldersと呼ばれるフォルダ群のフォルダは、APIにより削除や名前の変更はできません。また、この階層のフォルダは、すべてのドメインで共有できるフォルダと、アクセスできるドメインが限定される複数のフォルダから成っています※1)。つまりWebサイトからはストレージの最上位階層には共有フォルダとWebサイトのドメインからアクセスできるフォルダの2個が見えている状態になります。共有のフォルダは「Common」、それ以外の各ドメイン用のフォルダはGUIDによる名前が付いています。

ここまで説明した構造を図1に示します。

図1 ストレージの構造

図1 ストレージの構造

フォルダの階層は8段階までという制限があります。また、アップロードしたファイルの名前は変更できません(フォルダ名は変更可)。

※1

最上位のフォルダ構成などの仕様はSDK文書が整備されておらず、実際に使用したうえでの情報になります。

著者プロフィール

松江祐輔(まつえゆうすけ)

日本システムウエア株式会社 勤務。現在,ハードウェア設計・検証業務を担当。大学生・大学院生時代はベンチャー企業 有限会社ミレニアムシステムズにプログラマーとして従事。趣味はプログラミング。好きな言語はVisual Basic。Microsoft MVP for Windows Live Platform(Jul 2010 - Jun 2011),Windows Live(Jul 2011 - Jun 2013)。

URL:http://katamari.jp

コメント

コメントの記入