12日の明け方に、今まで使えていたエンドポイント（APIのURL）が使えなくなりあちらこちらで話題になっていた。具体的には

ttp://twitter.com/statuses/user_timeline/NNNNNN.xml

が使えなくなり

ttps://api.twitter.com/1/statuses/user_timeline.json

ttps://api.twitter.com/1.1/statuses/user_timeline.json

と、APIバージョンつきのURLを使ってね、ということ。

twitter公式発表だと、API 1.0 が使えるのは2013年3月までなので、この際ウチで使ってるtwitterのAPIなども1.1に変更した。

一次情報はこちら

https://dev.twitter.com

https://dev.twitter.com/docs/api/1.1

今まで意図通りに動いているスクリプト類は、1.1のエンドポイントに変更するだけでほぼOK。心配するほど大きな変更はなかった。

うちの場合データ取得などは、すべてXMLでやっていて、公式発表によると、RSS XMLは廃止、なので、jsonでの取得に切り替えた。twitterの公式ページには具体的なリクエストやパラメータなどが載っていて、サンプルもあって助かった。

mentions → mentions_timeline とバージョン番号の有無以外に変更になったAPIや廃止されたAPIもあるので、それは公式サイトを参照ください。

perlで作ったスクリプトでひとつひっかかったのがPOST。

1.0と同じデータを1.1のエンドポイントにリクエストすると、BadRequest 400が返ってくる。code 215エラーとか。1.0だと問題なかったのになんじゃそりゃ、と検索しまくってもそれらしい問題は出てこない。GETで取得するものは大丈夫。てことはOAuthでPOSTのリクエストに変更があったのか、と公式ページから辿ってみるとOAuthに関して、1.1は1.0よりもstrictになったらしい。でも、それならほかの開発者からも呪いの声が上がってるはず。公式ページを読んでも、OAuthのデータの作り方は今までと同じで問題ない。

あれこれ検索したり、CPANからNet::Twitterをダウンロードして眺めてみて、結論。

画像など添付のため、multipart form-data形式でのPOSTを受け付けるようになっていて、このPOSTは form-data なのか普通の（？）application/x-www-form-urlencoded なのかを明示する必要があったようだ。

これまでHTTPのヘッダのcontent_typeは何も指定せずそのまま通ってたんだけど

$req = HTTP::Request(POST， URL， POSTDATA )
$req->content_type(application/x-www-form-urlencoded)

と、指定することで無事解決。…ほぼ一日ハマってしまった。

POSTリクエストの一次情報はこちら

https://dev.twitter.com/docs/auth/creating-signature

昨日、WEBの表に出てるところは、すぐに気づいて直してまわって、やれやれ終わったぜ、と思ってたら、cronで使ってるものがあってすっかり忘れてた。

cronで使ってたのは「趣味は読書２」という公開中のWEB本棚サービスのtwitter連携。

twitterで本のタイトルや、著者名をつぶやくと、その本がすでに本棚に入ってるかどうかをリプライする。二重買い防止のため、本屋さんなどで「うーん、これ読んだっけ？」な時に重宝してる機能だった。