Kumasoftの開発記録: 2月 2013

2013年2月22日金曜日

Microsoft Translator APIで翻訳（改）その２

Microsoft Translator APIの使い方であるが次の手順でAPIを呼び出すことで翻訳ができる。

access_tokenを取得する
翻訳する

API呼び出しにはMicrosoft Translator APIの登録が必要になるがその方法については前のblogを参照してください。

また、これらAPI実行するにはHTTP POSTやリクエストヘッダへの値の設定が必要になる。普通にブラウザからURLを叩くだけでは実行できないので何かプログラムを作成するか、開発者向けのブラウザ拡張ツールを使うといいだろう。Chromeの場合Postmanというアプリを使っているが結構使いやすい。

access_tokenを取得する

access_tokenを取得するには、以下のリクエストURLにHTTP POSTでパラメータを送る。

リクエストURL: https://datamarket.accesscontrol.windows.net/v2/OAuth2-13
メソッド: POST

リクエストのパラメータには以下を指定する。

grant_type: client_credentials
client_id: アプリケーションの登録時に指定したクライアント ID
client_secret: アプリケーションの登録時に取得した顧客の秘密
scope: http://api.microsofttranslator.com

POSTするときはcontent-type=application/x-www-form-urlencoded で送ること。 multipart/form-dataで送るとは受信できないというエラーになる。

応答として以下のようなJSONが返ってくる。

{
    "token_type": "http://schemas.xmlsoap.org/ws/2009/11/swt-token-profile-1.0",
    "access_token": "http%3a%2f%2fschemas.xmlsoap.org%2fws%2f2005%2f05%2fidentity%2fclaims%2fnameidentifier=....",
    "expires_in": "600",
    "scope": "http://api.microsofttranslator.com"
}

このJSONにaccess_tokenが含まれているのでその部分の文字列をコピーする。 access_tokenには有効期間があって取得時から10分のようである。

翻訳する

翻訳は、以下のリクエストURLに先に取得したaccess_tokenと合わせてパラメータを送る。

リクエストURL: http://api.microsofttranslator.com/V2/Http.svc/Translate
メソッド: とりあえずHTTP GETで試してみた。POSTでもよい？

access_tokenはリクエストのヘッダに設定する必要がある。ヘッダ名Authorizationに値として Bearer (空白) (先に取得したaccess_token)を設定する。なぜ、Bearerという文字列をaccess_tokenの前につけるか謎だが必須になっている。 access_tokenは有効期限内ならば何度でも使えるようである。有効期限が切れたaccess_tokenを使うと400 bad requestのエラーになった。

リクエストのパラメータには以下を指定する。

from: 翻訳元言語のコード
to: 翻訳先言語のコード
text: 翻訳するテキスト

翻訳元言語と翻訳先言語にはこのページの一覧のものが使えるようである。

ためしに「こんばんわ」をスペイン語に翻訳する。Authorizationヘッダを設定してリクエストを投げる。

http://api.microsofttranslator.com/V2/Http.svc/Translate?from=ja&to=es&text=こんばんわ

結果が得られた。

<string xmlns="http://schemas.microsoft.com/2003/10/Serialization/">¡Buenas noches!</string>

スペイン語はよくわからないがたぶん合っているんだろう…

Microsoft Translator APIで翻訳（改）その１

以前の投稿で翻訳サービスのMicrosoft Translator APIの使い方を書いたのだが、書いた直後にAPIの利用方法が変わってしまっていた。久々に使う機会があったので再度調査し使い方をまとめてみた。

Windows Azure Marketplaceへの登録

まずはWindows Azure Marketplaceへの登録が必要となる。以下のURLより「Microsoft アカウント」でサインインをする。このアカウントは、以前はWindows Live IDと呼ばれていたものと同じではないかと思う。自分はそのIDでログインできた。持っていなければログイン画面の新規登録のリンクをたどって作成しする。 Windows Azure Marketplaceを初めて使うのであればいろいろ聞かれるので必要な情報を入力して登録を完了させる。

Windows Azure Marketplace
http://datamarket.azure.com/

Microsoft Translator APIのサインアップ

次にMicrosoft Translator APIの利用登録を行う。 Windows Azure Marketplaceにサインインした状態で以下のURLを開く。 Microsoft Translator APIは突き当りの利用文字数による従量課金だが、2,000,000文字/月までは無料なので、右のほうに値段の書いたメニューの一番下にあるサインアップを押し、必要な情報を入力してサインアップを完了させる。

Microsoft Translator
https://datamarket.azure.com/dataset/1899a118-d202-492c-aa16-ba21c33c06cb

サインアップ後は以下に現在どれだけ利用しているかが表示されるようである。

マイデータ
https://datamarket.azure.com/account/datasets

アプリケーション登録

Microsoft Translator APIを使用するには自分のアプリケーションを登録し、client_idとclient_secretというキーを取得する必要がある。 APIをサインアップした画面の下のほうに、小さい文字で「アプリケーションの登録」というリンクがあるのでそれを押すか、次のURLへ行く。

アプリケーションの登録
https://datamarket.azure.com/developer/applications/register

新しいアプリケーションの作成のために以下の情報を入力する。詳細には調べていないが、おそらくそれぞれの意味を持つ。

クライアントID: アプリにつけるID。他の人が既に使っているものと被らないものにする。
名前: アプリの名前。なんでもよい。
リダイレクトURI: Translator APIでは使わないが、登録に必須なので http://localhost/ など適当な値を入れる。httpだと安全でないと警告されるが無視

登録できたら、一覧に表示されるので「編集」を押してクライアント IDと顧客の秘密を記録しておく。これがそれぞれclient_idとclient_secretと呼ばれるものになる。

これでやっとMicrosoft Translator APIを使う準備が整った。長くなったので使い方はまた次回…

Google Driveでファイルを置き換え

Google Driveでファイルを置き換えるには次の手順でできる。

置き換えたいファイルを右クリック
「変更を管理...」を選ぶ
ダイアログに「新しい版をアップロード」のリンクがあるので押して置き換えたいファイルをアップロード

単純にアップロードしただけだと同じファイル名で古いのと新しいのが共存してしまうので、どうしたものかと今まで困っていたがこの方法で置き換えができるようだ。ただし、Google Driveは操作方法が頻繁に変わるので将来的にはやり方が変わるかもしれない。

2013年2月7日木曜日

JSONICでis-a関係を扱う

JSONとPOJO(Javaオブジェクト)を相互変換するのに JSONIC という便利なライブラリがある。実際の使い方はリンク先を見ていただくとして、単純な変換であればJSON→POJO、POJO→JSONとも1行のメソッド呼び出しで書けるのでとても楽。ただ、is-a関係のあるオブジェクトを含むJSONをPOJOに変換する場合にどうしたらよいのか今までやり方がわからなくて困っていた。たとえば、以下のような3つのクラスがあって、AとBがis-a関係、SとAが has-a 関係にあるとする。

public class A {
    private String fieldA;
    public String  getFieldA() { return fieldA; }
    public void setFieldA(String fieldA) { this.fieldA = fieldA; }
}

public class B extend A {
    private String fieldB;
    public String  getFieldB() { return fieldB; }
    public void setFieldB(String fieldB) { this.fieldB = fieldB; }
}

public class S {
    private A obj;
    public A getObj() { return obj; }
    public void setObj(A obj) { this.obj = obj; }
}

このときSのsetObj()にクラスBを持たせたPOJOをJSONに変換すると以下のようになる。

{
    "Obj" : { "fieldA":"～", "fieldB":"～" }
}

しかしJSONになると型情報がなくなるため、このJSONを以下のようにPOJOに逆変換すると S.getObj()で得られるインスタンスはクラスAになってしまう。

S myobj = JSON.decode(jsonText, S.class);

// o はクラスAのインスタンス
A o = myObj.getObj();

このときクラスBを再生するにはJSONICの変換ロジックをオーバーライドしてカスタマイズすることでできるらしい。このように変換方法をカスタマイズするにはJSON.decode()メソッドではなく、postparse()をオーバーライドしたJSONクラスのインスタンスを作りparse()メソッドで変換をするようにするらしい。少しややこしいが以下の方法でクラスBが再生できるようになった。

JSON json = new JSON() {
  // parse時の変換方法をカスタマイズする
  @Override
  protected <T> T postparse(Context context, Object value, Class<? extends T> c, Type type) throws Exception {
    // クラスAの変換であればクラスBとみなして変換をする
    if (c.equals(Class.A)) {
      return c.cast(super.postparse(context, value, Class.B, Class.B));
    }
    // クラスA以外ならば既定の方法で変換
    else {
      return super.postparse(context, value, c, type);
    }
  }
};
S myobj = json.parse(jsonText, S.class);

// o はクラスBのインスタンス
A o = myObj.getObj();

この例だとSのsetObj()にあるのはクラスBと決め打ちしてしまっているが、ここを動的に変えるような場合はpostparse()メソッドの中で引数valueの内容を判別して処理を分岐すればできるのではないかと思う。もしかするとannotationとか使うともっと楽なやり方があるのかもしれないが、まだよくわかっていないので今後の課題。

2013年2月4日月曜日

Facebook Graph API: February 2013 Breaking Changes 緊急修正

以下の連絡がFacebookから送られてきた

February 2013 Breaking Changes 緊急修正

あなたのアプリ「....」は、February 2013 Breaking Changesのために更新する必要があります。
アプリが対応したならば、アプリダッシュボードの詳細設定セクションの移行設定を「有効」にしてください。
この変更は2013年2月6日から1日以内に、すべてのアプリに永続的に適用されます。

何を意味している連絡なのかいまいち解りにくいが、メッセージ中にDeveloper Roadmap のページへのリンクがあり、Facebook Graph APIでの仕様変更があるので該当機能をアプリで使っている場合はすぐ修正せよという警告のようである。 2月6日というと明後日なのでいきなり言われても困るし、アプリでとくに該当機能は使っていなさそうなので何をするべきなのかは謎。アプリダッシュボードの詳細設定セクションの移行設定を「有効」にするだけでいいのだろうか…？

2/5追記

聞いた話だと、アプリダッシュボードの移行設定を「有効」にすると利用できなくなる機能に制限がかかった状態になるため2月6日以前に動作確認できるというものらしい。該当機能を使っていてもいなくてもこれが「無効」になっていると無条件で警告が飛んでくるような感じである。

該当機能を使っていない場合はどうやら放置しておいても問題ないようである。自分のアプリは影響なかったようなのでまずは一安心。ただし、認証関連の部分で大きい変更があるらしく、知っている方のいるところではこの方法を使っていたとのことで大騒ぎになったそうだ。

3月と4月にも March 2013 Breaking Changes, April 2013 Breaking Changesが控えているようだがこちらも今のところ大丈夫そうであった。

2/12追記

別のアプリではこの警告が今日来た。2/6期限のお知らせが今日来てもいかがなものかと思うが… 今日急にこのブログへのアクセスが増えていたのだが、もしかすると今日初めて警告を受け取った方々なのかも…

登録: 投稿 (Atom)