知識がなくても解決できていたのか？

一昨日辺りからOAuth実装してる。
アクセストークンを取るところまでは躓きながらもなんとかなった。
今はそこら中に実装されてるコードがあるから、いざとなったらコピペなんてこともできる。

今後はこのアクセストークンを利用するわけだが、TwitterへのツイートやFlickrへのアップロードとなるとまた小さな壁が登場する。
アクセストークンを取得するには必要最低限のルールで済むけど、APIを利用する際にはさらにちょっとだけ必要な知識が増える。
知識はちょっとでいいんだけど、デバッグとなると知識は大切…と改めて思った。
普段は別にそんなことも気にしないんだけど、仕事で「こういう構成で進めましょう」って話をすることが多いから、なるべく誰でもなんとかなるように…と考えているせいか、「この知識がなかったら解決できたのか？」と自問することがある。

軽くはまったこと

TwitterにツイートとFlickrに写真をアップロードで軽くはまった。
どっちも些細なこではあるんだけど、些細だから気付きにくいし…という面も併せ持っている。

Twitterにツイート

Twitterのタイムラインを取得するのは難なく出来たけど、ツイートはちょっと調べた。
原因はHTTP Headerにパラメータが含まれていたこと、これだけ。
もう少し詳しく書くと、ツイートに関するパラメータは署名対象に含める必要があるんだけど、HTTP Headerには不要。

今回遭遇したのはツイートするとなぜか {"errors":[{"message":"Could not authenticate you","code":32}]} と返ってくるというもの。
ネットで見る限り、このエラーコード32ってのがやっかいで、いろんなパターンにおいて発生している模様。
一言で言うと「認証は概ね合ってるけど、なんかちょっと違う」みたいな感じ。
GETとPOSTの間違いとか、エンコードがちょっと変(カンマの取り扱いを見かけた)とか、ヘッダーにもパラメータを含めてしまったとか、ちょっとしたことで遭遇する。

解決手段

今は便利なページがあって、必要な情報やリクエストを確認することが出来る。

▶POST statuses/update | Twitter Developers
https://dev.twitter.com/docs/api/1.1/post/statuses/update
このページの右サイドバーからアプリを選択して Generate OAuth signature を押す。
次のページで See OAuth signature for this request を押せばリクエストがどうあるべきかがわかる。
cURLコマンドも載ってるからこれを使えば実際のリクエストとレスポンスについて確認できる。

地道に比較するだけで解決できる。

Flickrに写真をアップロード

こっちの件は「そもそも、どういう形式で送ればいいんだ？」というところから始まった。

▶Flickr Services
https://www.flickr.com/services/api/upload.api.html
ここに書いてある通りなんだけど、普通にmultipart/form-dataでいいの？とか、filenameっているの？とか、そういうことが書いてない(別のページに書いてあるのかも？)。
「写真をアップロードするんだからmultipart/form-dataだし、filenameもいるだろう」と言われればそうなんだけど、APIも同じでいいのか？というのが疑問だった。
結果的には「ブラウザからのファイルアップロードのようなリクエストを送ればよい」という感じ。

上記のように仕様面での不安もあったけど、今回は慣れないGoで書いていたというのもあって、どのAPIを使えばいいのか？なんてのもわからなかった。
準備してあるAPIだとContent-Typeが不足していたり、そのAPIはどこまでやってくれているのかわからなかったり、そっちの面でも悩んだ。

アップロードがうまく行かなかった最大の原因は multipart/form-data; boundary="cd47c4f6086a7" のboudaryがなかったから。
リクエストを見るとpartの開始にはboundaryがあるんだけど、boundaryの指定がないんじゃない？…と気付くまでちょっと時間がかかった。

POSTの仕様を知らなかったら？

POSTでファイルを送るときの仕様をある程度知っていたから「boundaryの指定がないんじゃない？」って気付いて、APIを見てboundaryを取得する手段を探ったけど、POSTでデータを送るときの仕様を知らなかったら解決できていたのか？
最近の仕事ではこの辺の仕様を押さえていない人たちと一緒になることが多いから、こういうときどうすんだろ？せめてわからないことをわからないと言える環境は用意しておかないとな…と思ったりしている。

まとめ

あとでソースを整理してGitHubにでも置いておこう。
OAuthのライブラリを作りたかったわけではないので、やっとスタート地点という感じだけど、これで自分の好きなように出来る。
初めは既存ライブラリを使っていたんだけど、ファイルアップロードあたりが使いづらくてね…というか、Flickrのアップロードはphotoは署名には含めないし、photoはバイナリだし…というちょっと変わった仕様だったというのが理由。

POSTの仕様を知っているのは実装がきっかけだった気もするから、最終的には解決できていたのかもしれない。
そうなると、実装経験が少ない人は読書だけで役立つ知識となるのか？という疑問が生まれてくる。