2013年11月29日金曜日

Yahoo! テキスト解析API キーフレーズ抽出(送信機能作成編)

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

現在は巷にあるWebAPIの検証を行っています。

リクエスト送信機能

さて、WebAPIを実行するにはリクエスト送信機能が無くてはなりません。

HTTPリクエスト送信には一般に「Getメソッド」と「Postメソッド」があります。

本当はHTTPには「Deleteメソッド」とか「Putメソッド」とか色々と策定されているのですが、HTTPブラウザを初めとして送受信するソフトウェアの方が非対応だったりすることが多く、ほとんど使われていません。
「各メソッドはちゃんと決められたルールに則って使おう」という呼びかけもありますが、それが実現するのはまだ相当先となるでしょう。(永久に来ないかも)

というわけで、今回は「Getメソッド」と「Postメソッド」のみを考察します。

GetとPostの本来の用途は以下です。

  • Get:リソースの取得に使用する。(例えば、テーブルの主キーをGet送信して検索し結果を取得する、など)
  • Post:情報の送信に使用する。(例えば、入力フォームの全情報をPost送信してテーブルに保存する、など)

今回のテキスト解析APIは「テキスト解析結果を取得する」機能ですので、Getを使う方が標準と言えます。

しかし、Getメソッドの場合、Webサーバに最大長制限があります。
(Apacheの場合はデフォルトで「8190バイト」など。)

今回のテキスト解析APIでは、解析するテキストの長さがどれくらいになるか分かりませんので、
「Getで大量データを送信したらエラー」といったケースが想定されます。

その一方、Postにも上限はありますが、こちらはGetよりも大量データを送信出来ます。
(Tomcatの場合はデフォルトで「2メガバイト」など。)

この為、今回はPost送信を使います。

  • テーブルの主キー検索など、リクエスト長の上限が明確に決まっている場合はGetメソッド。
  • 今回のテキスト解析APIのテキスト送信みたいに、リクエスト長が不明 or 大量な場合はPostメソッド。

こういう使い分けにするのが合理的でしょう。

以下に私がJavaで作ったPost送信機能のサンプルソースを記載しておきます。
特に変わった機能は無く、普通に送信して、人間が目で見て分かりやすい形に出力するソースです。

HTTP通信は汎用的なプロトコルですので、JavaScript、PHP、Rubyなど、各言語でも作成できます。
各自の環境で都度、都合の良いように作れば良いでしょう。


public class RequestSender {

 /** logger */
 private Logger logger = Logger
   .getLogger(RequestSender.class);

 /**
  * リクエストをPOST送信する
  *
  * @param url
  * @param postBody
  * @return
  * @throws IOException
  */
 public String sendPost(String url, String postBody) throws IOException {

  //log4j使用
  //送信パラメータをトレースログに出力
  if(logger.isTraceEnabled()){
   logger.trace("送信先URL:" + url);
   logger.trace("リクエストボディ:" + postBody);
  }

  URL sendURL = new URL(url);
  URLConnection con = sendURL.openConnection();

  // POST送信モードを指定
  con.setDoOutput(true);

  // 送信実行
  OutputStreamWriter osw = null;
  BufferedWriter bw = null;
  try {
   osw = new OutputStreamWriter(con.getOutputStream());
   bw = new BufferedWriter(osw);

   // POSTの内容を書き出す
   bw.write(postBody);

  } finally {
   if (bw != null) {
    bw.close();
   }
   if (osw != null) {
    osw.close();
   }
  }

  // 受信
  InputStreamReader isr = null;
  BufferedReader br = null;

  StringBuilder bul = new StringBuilder();

  try {
   isr = new InputStreamReader(con.getInputStream());
   br = new BufferedReader(isr);

   String line;
   while ((line = br.readLine()) != null) {
    //肉眼で見やすいように改行コードを付与
    bul.append(line).append(System.getProperty("line.separator"));
   }

  } finally {
   if (br != null) {
    br.close();
   }
   if (isr != null) {
    isr.close();
   }
  }

  //apachecommons使用
  //最後の改行コード削除
  return StringUtils.chomp(bul.toString());

 }

}


リクエスト発行編へ


文面が長くなってきましたので、今回はここまで。
次回はいよいよ、上記ソースを使ってレスポンスの中身を検証してみます。

2013年11月18日月曜日

Yahoo! Web API 登録編

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

しばらくは世に溢れる「WebAPI」の機能について検証していきたいと思います。

最初はヤフーのWeb APIです。

Yahoo! Web API


YahooはWebAPIをいくつも提供しておりまして、その種類も豊富。
WebAPI界の大御所と言えるでしょう。

しかも良い所は、日本語の説明ドキュメントがある点ですね。
Google、FaceBook、Twitter辺りだと英語しか無いので、大変助かります。

公式サイトは以下です。


さて、早速テキトーにリクエストを投げて……ん?



どうやらリクエスト送信には「アプリケーションID」の取得が必要なようですね。

このようにWebAPIにはIDの取得を求められることが多いです。
WebAPIは使えば使うほど、WebAPI側のネットワークやサーバの負荷が掛かりますので、誰がどれくらい使っているかを管理する為にIDが必要ということですね。

従量課金制になっている所も多く、リクエストが多いIDほど、多くの金が取られるということです。



  • WebAPI業者はIDで使用者を管理している。



逆に言いますと、「IDさえ分かればなりすまし可能」という意味ですよ。

つまり、「JSファイルにIDをベタ書きして、Ajaxでリクエスト発行」とかやるとJSソースを解析されてIDが盗まれますので、
大事なIDはサーバ側で保管しておき、WebAPI発行はサーバ側から行うと良いでしょう。




  • WebAPIのリクエスト発行はクライアントサイドからAjaxでも行えるが、セキュリティを考えるならサーバから発行した方が良い




以上、簡単なことですが大事なことなのでお忘れ無く。


アプリケーションID取得


では、本題のアプリケーションID取得に入りましょう。

YahooJapanにログインしている状態で以下のページにアクセスします。





ここの「新しいアプリケーションを開発」のボタンをクリックします。


すると、以下のような画面が表示されます。
(メアドが表示されていますので、その部分は隠させて頂きました)



これを見ると、「サーバサイド」「クライアントサイド」と、利用目的に応じて違う設定が必要なようです。
クライアントサイドの方に「OAuth 2.0 Implicit」と書いてありますが、これは超巨大なセキュリティホールが出来るという噂の認証方式……。
今回は「サーバサイド」を選択して進んでみようと思います。


そこから先に続くのは「アプリケーション名」や「サイトURL」等ですが、今回は動作検証用ですので、
デフォルト値のままにしておきます。

最後に「同意」を選んで確認ボタンをクリックしますと、確認画面を表示した後に、IDの取得が完了します。

次の画面に進んだ時には、もうIDが発行されています。
(モザイクで見えなくさせて頂いておりますが)



簡単ですね!!

アプリケーションIDは「ハッシュ値」みたいな文字列です。

上記にもありますが、アプリケーションIDは大事な値ですので、推測も出来ないようになっていなければなりません。
更に一意性も必要ですので、「ログインID+シーケンス番号した文字列をハッシュ変換」といった方式で出力しているものと推測されます。

そしてもう一つ、「シークレット」というものが出ています。
これにつきましては、調べたのですが詳細が分かりません。
YahooにはユーザIDがバレてもログイン出来なくする「シークレットID」なる機能もありますが、こちらはそれとは別物の模様。
詳細が分かり次第、記事にしたいと思います。


さて、これでIDの取得は完了です。
もうWebAPIを発行出来る状態になっています。

試しに、画面に表示されているサンプルリクエストを送信してみました。



ちゃんとレスポンスが返ってきていますね。
これで動作確認も取れました。

後は発行するだけでOKです。
実に簡単でした。

次回


次回からは、いよいよ本格的にWebAPIの機能検証に入ります。

2013年11月5日火曜日

WebAPI 導入編

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

今回から「WebAPI」の連載をスタートしたいと思います。

WebAPIとは

連載のテーマであるWebAPIとは、特に厳密な定義があるわけではないのですが、要するにインターネット経由で余所からデータを取ってくる機能のことです。

例を挙げるとすると、ヤフーのニュース記事の下にあるTwitter部分。



これです。
これはヤフーのその記事と関連のあるツイートを表示しているわけですが、これをどうやって取得しているのかと言うと、Twitterが提供しているWebAPIを利用しているのです。


カラクリとしましては、HTTP通信でリクエストを投げると、レスポンスで「XML」か「JSON」かの形式で返ってきますので、それをパースして……。
と難しい話は以降の連載にしましょう。

ようするに、「リクエストを送信すると文字列が戻ってくるので、それを画面に出す」というだけのシンプルな機能です。

もちろん、こういった機能は自前で作ることも、別に難しいことではありません。
自前でWebAPIを作って公開し、使用料を取るというビジネスも普及しています。

WebAPIのニーズ

このWebAPIというサービス形態は昨今……というにはちょっと遅い気もしますが、最近注目のサービスです。
理由としましては、やはりスマートフォンやタブレットといった次世代携帯端末の存在でしょう。

これらの機器は内部にアプリを入れて機能するわけですが、やはり携帯端末ですのでリソースが少なく、そんなに重い機能を実装出来ないのです。
そこで、重い処理はWebAPIを動かしている巨大サーバで行って、必要な情報だけを取得して携帯端末に表示する。
そんなエンドユーザ端末の機器に優しいことがWebAPIの長所です。

WebAPIの現状

とは言え、私はWebAPIを使ったシステム開発は一度しかありません。
注目度の割にはあんまり出番が来ないサービスというイメージがあります。

その理由として、二つの理由を考えてみました。

1.出番が無い


まずはこれでしょう。
「Twitterの情報を取得したところで遊びにしか使えないじゃないか」みたいに、不特定多数のエンドユーザを想定したサービスが多いです。
元からオシャレなスマホアプリ作成を生業としている人ならともかく、私のような企業向け業務システム開発が中心のエンジニアには滅多に使用機会が訪れないのです。

2.お金&余所様のデータであること


もう一つの理由は、これ。
WebAPIはどこまで行っても他社様のデータを貰ってくるサービスですので、契約とか権利とかの理由で、業務用には敬遠されてちまいがち。軽く使いたいだけでも「法務部」とかそんなレベルの話になってしまい、内部調整が非常に大変です。

何より困るのが「仕様変更」ですね。
少し前にTwitterが急に仕様変更したせいで取れていたデータが取れなくなり潰れたサービスがありました。
WebAPI提供業者の都合に振り回されてしまうのも欠点です。

WebAPIの利用価値

このように難点も多いWebAPIですが、一方で凄く便利で高機能なサービスがあるのも確かです。

業務用システムエンジニアである私の立場では、「天気予報取得」「居酒屋の口コミの取得」など永遠に出番が無さそうなサービスも大量にありますが、中には「漢字に読み仮名を降る」「PDF変換」など、もしかしたら使い道もありそうな雰囲気のサービスもちらほら見かけます。
興味が湧いてきましたね。

というわけで、今回の連載では「業務用システムエンジニアから見たWebAPI」というテーマで、調査したWebAPIのご紹介をしていこうと思います。

次回予告

最初はヤフー提供のWebAPI『テキスト解析API』から調査開始です。