たまに日記: 3月 2012

2012年3月6日火曜日

twitter api 2

twitter api を試してみる。

昨日試したのはREST APIのsearch。 xxxxは検索文字
curl http://search.twitter.com/search.json?q=xxxx

Twitter Search APIのsearchを試す。xxxxは検索文字
curl https://twitter.com/#!/search/realtime/xxxx%20since:2012-03-05

って普通に検索ページのhtmlが返却される。

でも検索ページで指定出来る条件は、REST APIでも指定できるっぽい。

○2012-03-04以降で、http://www.yahoo.co.jpが含まれるツイートを取得。

http://search.twitter.com/search.json?q=http%3a%2f%2fwww.yahoo.co.jp&since=2012-03-04

○2012-03-05以降で、@twitter_idが含まれるツイートを検索。
http://search.twitter.com/search.json?q=%40twitter_id&since=2012-03-05

前・次のページを取得する時は、
jsonデータの「next_page:」のパラメータで検索すればいい。
max_idを指定して改ページする。

○ 2012-03-04以降で、http://www.yahoo.co.jpを含むツイートで、
1ページ１００件表示の１ページ目を取得。

http://search.twitter.com/search.json?page=1&q=http%3A%2F%2Fwww.yahoo.co.jp%20since%3A2012-03-04&rpp=100

で2ぺージ目以降は、↑で取得したJSONの「next_page:」のパラメータで検索。
page: 15になったところで、改ページを終了する。
16以降は１ページ目のデータが戻されている。

2012年3月4日日曜日

twitter api

自作のアプリからtwitter api を使って、対象のURLが含まれるツイート数をカウントしたい。
でも、documentを見ても、そんなメソッドはない。
https://dev.twitter.com/docs/api

searchメソッドを使えば、実現できそうだが、過去1500件までしか遡れない。

調べてみると、twitter button内で使用されている
https://cdn.api.twitter.com/　で取得できる模様。
https://cdn.api.twitter.com/1/urls/count.json?url=http://www.yahoo.co.jp/　で、以下の結果が返ってきた

{"count":222207,"url":"http://www.yahoo.co.jp/"}

でも、ためしに自分のドメインをツイートして、その数をカウントすると

3とか表示される。

ためしに、会社のURLをツイートすると、ちゃんと1って表示された。

documentに記載がないので、いまいち使い方がわからない。

あと、日付指定とかできないのかな？

ぐぐってみると、topsyのotterapiってのでURL含むツイートの検索が出来るようだ。
http://code.google.com/p/otterapi/wiki/Resources

■参考ページ
http://d.hatena.ne.jp/a_kimura/20110429/1304078734

うんなんかよい感じでカウントは取得できた。
ただ、日付指定しての検索はできないなっぽいな。。

う～ん結論としては、該当のURLが含まれるツイート数のトータルを取得するのは、
できそうだが、日付指定してのツイート数は出来ないようだ。
たとえば今日1日で対象URLを含むツイート数とか。

クロスドメインでのiframe

できること

jsでのparent参照。

できないこと

jsでのparent.document参照。

window.postMessage()を使おうとしたが、

最新のfirefox,safari,chromeでは使えそうだが、

IE6では使えない。

子に親と同じドメインの孫windowをiframe読み込んで、
孫フレームから、親へアクセスと言うのが出来るらしい。
が、親ドメインへ孫HTMLファイルを配置する必要がある。

RESTとは

RESTってなにかよく分からなかったので、wikipediaで調べてみた。

HTTP、HTTPSで通信。
データのフォーマットは、XML、JSON、HTML、RDFなど

ざっくりしすぎ。

1の補足

HTTPSでの暗号化が可能。
ステートレスな通信（メッセージの一つ一つがそのリクエスト (メッセージ) を理解するために必要な全ての情報を含む。）
ブラウザで簡単に動作確認が出来る。テスト用プログラムを作成する必要がない。
一意なURIでリソースの位置が特定される。

２は、用途に適したさまざまなフォーマットがある。

RESTは「RESTでは不特定多数を対象にした、入力パラメータが少ない情報配信や検索サービス等での利用に向いている。」
らしい。