mixiアプリ » 技術仕様(RESTful API方式) » PC » よくあるご質問
よくあるご質問
ここでは、mixiアプリを開発する際に知っておくと便利なことを紹介します。
利用者の成りすましについて
不正にmixiアプリの利用者を成りすますことを防止あるいは成りすまされたことを検知するには、どうしたら良いでしょうか?
Person & Friends APIを利用すると、mixiアプリの利用者のユーザIDなどを取得することができます。多くのmixiアプリにおいて、取得したユーザIDとそれに関する情報をバックエンドサーバ(=外部のサーバ)に送信し、データベースに格納する処理が行われています。その際に指定されるユーザIDは、「そのmixiアプリを実際に誰が利用していたか」を示す非常に重要な情報です。これが不正に改ざんされた場合、悪意を持って別のユーザに成りすましてmixiアプリを利用することができてしまいます。
mixi Platformでは、署名付きリクエストと呼ばれる外部サーバとの通信方式を提供しています。これは、mixiアプリから外部サーバに何らかの情報を送信する際に、その内容に署名を付けて送信することで、受け取った外部サーバにて改ざんされていないかどうかをチェックすることを可能にする機構となります。
[署名付きリクエスト]
http://developer.mixi.co.jp/appli/spec/pc/require_servers#toc-2
この署名付きリクエストを利用すると、実際にそのmixiアプリを利用していたユーザのIDを、mixi Platformにて自動的に追加し、そのIDを加味した署名が付与されます。ユーザIDの付与は、Webブラウザ上ではなく、外部サーバと直接通信することになるmixi Platformのサーバによって行われます。そのため、悪意を持ったユーザが、利用者のユーザIDを不正に改ざんすることは困難です。また、外部サーバにて行われる署名の検証では、自動付与された利用者のユーザIDも対象となるため、通信経路中に行われた改ざんも検知することが可能です。
署名付きリクエストによって、外部サーバに情報を送信(gadgets.io.makeRequest)する際に、以下のパラメータが付与されます。
- opensocial_owner_id – 対象アプリを所有するユーザのID
- opensocial_viewer_id – 対象アプリを利用していたユーザのID
- opensocial_app_id – 対象アプリのID
PC向けmixiアプリを開発する際に、「誰の情報を取得あるいは更新するか」といった情報の送受信を行う場合には、必ず署名付きリクエストを利用してください。そして、そのmixiアプリの利用者のユーザIDを外部サーバに送信したい場合には、署名付きリクエストにて送信されるopensocial_viewer_idパラメータの値を採用するようにしてください。もちろん、opensocial_viewer_idパラメータの値が通信経路中で改ざんされている可能性もあるため、署名の検証も同時に行ってください。Flashを使ってmixiアプリを開発されている場合に関しても、同様の施策を行うと良いでしょう。
mixiアプリの起動時間について
mixiアプリの起動にとても時間がかかります。その原因の一つとして、友人一覧の取得にとても時間がかかっていることがあげられます。なんとか起動時間を早めるためにはどうしたら良いでしょうか?
弊社では、現在mixi Platformの安定稼動に向けて、サーバの増強およびサーバプログラムの改善を行っています。それに加えて、mixiアプリの開発者の方々におかれましても、自分のmixiアプリの起動時間を早めるための改善を独自に行うことができるケースがございます。mixiアプリそれぞれが最適なAPIの利用をすることで、mixi Platform全体の安定稼動にもつながります。
ここでは、mixiアプリの起動に必要な時間を減らすためのテクニックについて、いくつか紹介いたします。
mixiアプリを所有する友人のみの取得
People APIを使って友人一覧を取得する際に、そのアプリを既に利用している(=所有している)ユーザのみを取得すれば良いことがほとんどだと考えられます。
var idSpec = ...; var req = opensocial.newDataRequest(); var params = {}; params[opensocial.DataRequest.PeopleRequestFields.FILTER] = opensocial.DataRequest.FilterType.HAS_APP; req.add(req.newFetchPeopleRequest(idSpec, params), "friends"); req.send(function(data) { var friends = data.get("friends").getData(); friends.each(function(friend) { // do something... }); });
上記のコードのように、FilterType.HAS_APPを利用することで、mixiアプリを持っているユーザのみをリクエストすることができます。これにより、無駄な情報の取得を削減することが可能となるため、mixiアプリの起動時間を早めるためには非常に効果的な手段と言えます。
mixi Platform全体への負荷軽減をHAS_APPフィルタによってもたらすことも可能となるため、ぜひこの機能を積極的にご利用ください。
一度に取得する友人数
ソーシャルアプリケーションは、自分もしくは自分に関係するユーザーの情報を数多く扱います。mixiにおけるユーザー間の関係は、友人となります。一人当たりの平均登録友人数は25人前後ですが、mixiを頻繁に利用しているユーザであればあるほど、登録している友人数は多いと考えられます。
mixiアプリは、People APIを利用することで、友人の情報を取得することができます。そのために、 opensocial.DataRequest.newFetchPeopleRequest()関数を使用します。この関数を利用する際に、いくつか指定可能なパラメータが定義されていますが、その中に「1回のリクエストあたりの最大件数」という指定があります。
Static Class opensocial.DataRequest.PeopleRequestFields <static> object MAX フェッチするアイテムの最大数です。数値として指定します。
MAX値を明示的に指定しなかった場合は、20が適用されます。つまり、20人の友人情報を取得することになります。この数字を大きくすればするほど、1リクエストにて取得可能な人数が増えることになります。そして、数字を大きくすればするほど、処理時間および情報の転送量は大きくなります。友人の取得処理は、ほとんどのmixiアプリにおいて最初に行われる処理です。そのため、この数字が大きければ大きいほど、mixiアプリの起動時間が遅くなると言うことができます。
mixiアプリに割り当てられる画面サイズは比較的小さく、一度に表示可能な友人数も限定されます。そのため、多くのmixiアプリにおいて、ViewerもしくはOwnerの友人全員を一度に取得する必要性は低いと考えられます。mixiアプリの起動に多くの時間をかけてユーザに待機時間を与えるよりも、できるだけ早く利用することができたほうがユーザビリティという点でも有利です。
MAX値の指定は、以下のようにして行うことが可能です。
var params = {}; params[opensocial.DataRequest.PeopleRequestFields.MAX] = 10; var req = opensocial.newDataRequest(); var idSpec = ...; req.add(req.newFetchPeopleRequest(idSpec, params), "friends"); req.send(...);
つまり、mixiアプリの起動時間を早めるために、
- MAX値に指定する値は、必要最低限とする。
- FIRST, MAXを利用して、友人表示にページング機能を導入する。
といった工夫を行い、Ajaxという非同期性をうまく利用するようにしましょう。
一度に取得する項目
mixiアプリが扱うことができるユーザの項目として、以下の項目があります。ソーシャルアプリケーションとして、以下の項目を駆使することで、魅力的なmixiアプリを作ることができるでしょう。
- ID, ニックネーム, プロフィール写真, プロフィールURL, 現住所(県のみ), 年齢, 生年月日, 性別, 血液型
これらの情報は、opensocial.DataRequest.newFetchPersonRequest()関数もしくは opensocial.DataRequest.newFetchPeopleRequest()関数を使うことで、ユーザの情報として得ることが可能です。しかし、明示的に取得する項目を指定しなかった場合、結果に含まれる項目は以下の3つに限定されます。
- ID, ニックネーム、プロフィール写真
この3つ以外の項目を取得したい場合は、opensocial.DataRequest.PeopleRequestFields.PROFILE_DETAILSを利用します。
Static Class opensocial.DataRequest.PeopleRequestFields <static> object PROFILE_DETAILS opensocial.Person.Field の配列です。Person オブジェクトごとにどのプロフィール データをフェッチするかを指定します。
ほとんどのmixiアプリにについて、全ての項目を扱う必要はなく、例えば上記3つに加えて性別のみ取得すれば事足りるでしょう。一度に取得する項目の数を多くすればするほど、処理時間および情報の転送量は大きくなります。取得件数と同じように、ユーザ情報の取得処理は、ほとんどのmixiアプリにおいて最初に行われる処理です。そのため、項目数が大きければ大きいほど、mixiアプリの起動時間が遅くなると言うことができます。MAX値を大きく指定した上で全ての項目を取得しようとした際は、友人数によってはmixiアプリ起動時間に明らかな影響を与えます。
PROFILE_DETAILSの指定は、以下のようにして行うことが可能です。
var params = {}; params[opensocial.DataRequest.PeopleRequestFields.PROFILE_DETAILS] = [opensocial.Person.Field.GENDER]; var req = opensocial.newDataRequest(); var idSpec = ...; req.add(req.newFetchPeopleRequest(idSpec, params), "friends"); req.send(...);
つまり、mixiアプリの起動時間を早めるために、
- PROFILE_DETAILSを使って、必要最低限の項目のみを取得する。
といった工夫を行うようにしましょう。
ライブラリの使用
mixiアプリの開発に必要となるJavaScriptコードの記述を簡略化し開発生産をあげるために、いくつかのライブラリが開発されています。mixiアプリにおいて、そのようなライブラリを利用して開発されたものも多いことでしょう。
JavaScriptの記述量を抑えて簡潔にコーディングを行うことができる反面、ライブラリの挙動を知ることなしにmixiアプリが出来上がってしまう、というデメリットも考えなければなりません。特に、OpenSocial API向けのライブラリの使用については、以下のような挙動をするライブラリが存在します。
- MAX値として暗黙的に1000が指定されている。
- PROFILE_DETAILSとして、OpenSocialにて規定された全ての項目が指定されている。
もし上記のような実装のライブラリを使ってmixiアプリを開発した場合は、mixiアプリの起動処理やその他APIアクセスについて、無駄な処理が大きく発生していることになります。開発したmixiアプリの動作だけでなく、mixi Platform全体の負荷向上を招く可能性も出てきます。
もしOpenSocial対応もしくはmixiアプリ対応と表明されている何らかのライブラリをご利用の場合には、MAX値や PROFILE_DETAILSについて、最低限必要となる値や項目を明示的に指定するようにすることで、mixiアプリの起動時間などを改善することができるでしょう。
Gadget XMLファイルのキャッシュについて
mixiアプリを開発していて、Gadget XMLファイルの変更をしたとしても、何故か反映されません。どうしたら反映されるのでしょうか?
mixiアプリでは、様々なレイヤーで強力にキャッシュが働きます。これは、mixiアプリの動作に関する負荷をできるだけ減らして、利用者に快適にアプリを利用してもらえるようにするための工夫です。しかし、mixiアプリの開発において、そのキャッシュが開発の妨げになってしまうケースも十分に考えられます。
ここでは、開発の妨げになりやすいキャッシュの制御方法を解説します。
Gadget XMLファイルのキャッシュ
mixiアプリの必須構成要素であるGadget XMLファイルに記述された内容は、mixiアプリが動作する際に必ず必要となります。登録されたGadget XMLファイルのURLに毎回アクセスすることは合理的ではない(開発者のWebサーバに不必要な負荷をかけてしまうため)ので、mixiのサーバ内にキャッシュされることになります。
開発が終了したあとのことを考えると、このキャッシュ機構は非常に有効です。しかし開発時には、Gadget XMLファイルの内容を変更しWebサーバに再アップロードしたとしても、mixiのサーバに既にあるキャッシュが使われてしまうことによって、開発者が施した変更が適用されないという状況となります。
そのため、明示的にmixiのサーバにあるキャッシュを無効にするための方法を2つ提供しています。
- mixiのサーバ内のキャッシュを消去し、Gadget XMLファイルを再読み込みさせる。
- mixiのサーバ内のキャッシュを一時的に無効とし、最新のGadget XMLファイルを読み込ませる。
mixiのサーバ内のキャッシュを明示的に消去し、Webサーバ上でのGadget XMLファイルの更新をmixiアプリに反映するために、アプリ変更ページの「キャッシュ消去」ボタンを押してください。
開発中などでキャッシュを一時的に無効にしたい場合は、URLのパラメータにnocache=1をつけます。このパラメータは、mixiアプリが表示されるすべての画面で利用可能です。注意点として、このパラメータは今現在のユーザーのキャッシュを一時的に無効にするだけであり、nocache=1 を付けずに画面を開いた際には、すでにmixiのサーバに存在するキャッシュが再度使われることになります。全てのユーザに対して最新のGadget XMLファイルの記述内容をmixiアプリに反映させたい時には、上記のキャッシュ消去ボタンを使用するようにしてください。
http://mixi.jp/home.pl?nocache=1
http://mixi.jp/run_appli.pl?id=1&nocache=1
外部リソースや外部サーバへのアクセスに関するキャッシュについて
JavaScriptファイルやCSSファイル、画像などを変更しても、何故か反映されません。また、外部サービスへのアクセスの結果についても同様です。どうしたら良いでしょうか?
現在、jsファイルや画像などの静的ファイルのcontent-rewriteによるキャッシュは行っておりません。また、外部サービスへのアクセスに関しても同様にキャッシュされていません。
Gadget XMLファイルやJSファイル、makeRequest関数によって取得したコンテンツ内の静的ファイルへの参照は、そのままWebブラウザに反映されます。もしこれらの静的ファイルについて変更が反映されない場合は、Webブラウザのキャッシュ機構やネットワークの経路にある何らかのプロキシサーバのキャッシュ機構による原因が考えられます。
mixiサーバからのアクセスについて
mixiサーバからのリクエストのみを受け付けたいため、mixiサーバのIPアドレスを教えてください。
mixiのコンテナのIPアドレスの公開予定は未定となっております。 また、mixiサーバの各IPアドレスは変更されることがあります。
makeRequest()関数による署名付きアクセス
mixiサーバからのリクエストかどうかを判断する方法として、makeRequest()関数のパラメータに、
opt_params[gadgets.io.RequestParameters.AUTHORIZATION] = gadgets.io.AuthorizationType.SIGNED
を渡すことで、リクエストに署名を付与することが可能です。通信先のサーバ側でこの署名を検証することにより、リクエストが本当にmixiサーバから来たのかどうかを判断することができます。詳しい利用方法は、下記のページをご覧ください。
http://developer.mixi.co.jp/appli/spec/pc/require_servers
JavaScriptファイルの読み込みについて
Gadget XMLファイル内でJavaScriptファイルを<script>タグで読み込みたいのですが、読み込まれていません。なぜでしょうか?。
<script>タグのsrc属性を使って外部のJavaScriptファイルを読み込む際に、そのURLは「http://」から記述される完全なURLを記述してください。”scripts/foo.js”などといった相対的なURLの記述では、JavaScriptファイルは読み込まれません。具体的には、
<Module> <ModulePrefs>...</ModulePrefs> <Content type="html"><![CDATA[ <script type="text/javascript" src="http://example.jp/script/app.js"></script> ]]></Content> </Module>
というように記述を行ってください。
DOCTYPEについて
開発したmixiアプリのレイアウトがIEで崩れます。DOCTYPE宣言を指定したいのですが、どうすれば良いでしょうか?
Gadget XMLファイルにて、DOCTYPE宣言を出力するための記述を行うことが可能です。具体的には、Content要素にquirks属性を記述します。
<Content type="html" quirks="false" ...>
この記述によって、以下のようなDOCTYPE宣言が出力されるようになります。
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">