SlimTimer APIの泣き所

少々遅くなってしまいましたが、backlog2slimtimer / importActualHoursで対象としたSlimTimer APIを用いた開発について、詰まったところをお話します。少しでも後学の人の参考になればと。

意外(?)なほどに、Javascript + SlimTimerの組み合わせが少なくて苦労しました。ちょっと取り上げた、remember the milk のタスクを選択して SLIMTIMER に送り込めるユーザスクリプト - ドレッシングのようなぐらいしかなかったんですよね。単純に事例が少ないだけならばともかく、ドキュメントとマッチしていないことも多々あって、またそこに苦労しました。


一度認証に失敗すると、以降ずっと認証エラーとなる

私の環境では、パスワード誤りなどでいったん認証に失敗すると(正しいパスワードに修正しても)Firefoxを再起動しないとずっと認証エラーとなってしまいました。不正アクセス防止用に、認証情報失敗したクライアントはSlimTimer側でキャッシュしているのかもしれません。

backlog2slimtimer(正式バージョン)リリース! - @ikikko のはてなダイアリー

一番最初にはまったのが、ちょっと前にも触れたこれです。ブラウザからはアクセスできるのに、API経由だと延々と弾かれ続けました。失意のまま寝て、一晩起きてからやってみるとうまくいったという現象が分かったとき、もしかしてこういうことなのかなという推測が立ちました。

API提供者側としては分からなくはないのですが、(もし推測どおりならば)せめてドキュメントには書いていて欲しいです。。。orz

access_tokenなしでAPI発行すると、ある特定の人のタスクを参照する

これは半分自分のミスもあるのですが。

SlimTimer APIでは、まず各個人で恒久的なAPI Keyと(ユーザ/パスワード)の組から、一時的なaccess_tokenを発行します。で、実際の処理ではこのaccess_tokenを認証キーとして用いるようになっています。

このaccess_tokenですが、最初記述ミスで付け忘れてタスク一覧取得メソッドを発行していたのですよね。そうすると、なぜか赤の他人のタスクが取得できてしまいます。この現象に出くわした当初はいみふだったのですが、バグを回避した後で考えると、SlimTimer運営側のテスト用に存在するアカウントなのかなと思いました。いわゆる、バックドア的な。

JSONでのレスポンスがJSON.parseでパースできない

個人的に、一番がっくしきたのはこれ。レスポンスのJSONをevalではパースできるんですが、JSON.parseでは正常に動作しません*1。原因は、JSONオブジェクトのキーが、クォーテーションされていないから。

ここで注意することはキーとして使うデータ型は文字列に限ることである。したがって、
  {name: "John Smith", age: 33}
という表記は許されない。この後者の表記はJavaScriptのオブジェクトの表記法としては正しいが、JSONとしては不正な表記である。

JavaScript Object Notation - Wikipedia

仕方ないので、いったんapplication/xmlで受け取ってそれをそのままjQueryオブジェクトに変換してやり、あとはjQueryのタグセレクタでひっかけるというやり方を取りました。

SlimTimerのドキュメントサンプルでは、ちゃんとダブルクォーテーションで囲まれているのに…><

Response
As you may have guessed the Accept header is used for the format the data is returned to us from the system. Responses may be formatted as XML or YAML just as requests but they may also be formatted in JSON like so:
  {"access_token": "a74d823ecf63f481d92b1e52853fa4bcbe2239d1", "user_id": 1}

SlimTimer - Time Tracking without the Timesheet


Javascript(&Greasemonkey)をまともに触ったのが初めてだったので、JS側とSlimTimer側の問題の切り分けに結構苦労しました。今思うと、UxUによるGreasemonkeyスクリプトのテスト - クリアコードとか使ってユニットテストをやってもよかったのかもしれません。実業務だと時間の制約などもあって中々手出しにくいときもあるけど、プライベートだとどんどん幅広げていけるしいかんといけんしですね。

*1:うろ覚えですが、確かエラーがはかれたかと