弊社、ChatWorkやめるってよ
会社でChatWorkを使っていたのですが、Microsoft Teamsに移行するとお達しがありました。過去のデータが見れなくなっちゃうといつか困るかもしれないので、WEB APIを使ってバックアップを取ろうと考えました。残念ながらChatWork側のWEB API仕様としてメッセージは直近100件分しか取得できない1のですが、まあないよりはマシということで・・・
せっかくなので推しのRed言語でやるぞ！
ソースコード
ひとまずの出来上がり品がこちら
GitHubのリリースページでバイナリとしても配布しています。色々と機能追加・リファクタリングの余地はありますが、残念ながらすでに会社がChatWork解約済みのためリポジトリの更新は停止する予定です。
RedでWEB APIが関わるツールを実装する魅力
Redでアプリを作るのはちょいちょいやっていましたが、社内の他の人にも使ってもらったのは今回初めてでした。問題なく他の人の環境でも動いてくれて満足しています。
RedはまだVer1.0になっておらず、互換性のない変更も予想されるため、プロダクションで使用するのはリスクがある状況です。一方でちょっとしたツールを作成するには十分な能力がすでにあります。Redは特にCSV、XML、JSONなどのデータを処理するときや、今回のようにWEB APIが絡むツールをカジュアルに開発するにはとても便利&快適に開発できる言語です。
でもデータを処理するって普通なんでもそうじゃね？つまり最高だってことですわ。
以下に、なぜRedが便利&快適なのかについて、まとめてみました。
1. 標準REPL & 公式VS Code拡張機能で十分開発できる
2.ノートPCで十分開発できる
3.記号が少ない。Shiftキーを使う頻度が少ない
4.他の人の環境で簡単に動く
5.WEB APIの呼び出し＆ハンドリングが楽
1.標準REPL & 公式VS Code拡張機能で十分開発できる
Redは標準でREPLが付いています。また、公式のVS Code拡張機能があるのでVS Code派の人はこれで十分でしょう。他のエディタ派の方でもRebolという言語のシンタックスハイライトにエディタが対応していれば概ね代替可能だと思います。
2.ノートPCで十分開発できる
上記と関連しますが、ごついでかいIDEでなくても開発できるので、それほど高スペックではないノートPCでも十分開発できます。自分はあまりプライベートであまりPCにお金をかけたくはないタイプで、安価なノートPCで開発していますが、Redでちょっとしたツールを作るのはノートPCでも十分可能です。
3.記号が少ない。Shiftキーを使う頻度が少ない
これが快適すぎてRedから離れられないのです・・・
ソースを見てもらうとお分かりいただけると思いますが、他の言語でよく使う記号、, . : ; {} () _がとても少ないです。主に使う記号は: と [] ですが、この2つは日本語キーボードで打ちやすいですし、種類も少ないのでだいぶ快適です。Shiftキーを押す頻度が少ないのがとても楽。Shiftキー、部屋が寒いときとかミスタイプ増えませんか？笑
4.他の人の環境で簡単に動く
Redは単一バイナリにコンパイルでき、実行にランタイムのインストールは不要です。そのため、完成したツールを他の人に渡して使ってもらうのが非常に気楽で助かりました。
ちなみにファイルサイズですが、コンパイル直後は1.14MBありましたが、機械語のバイナリなのでUPXで圧縮可能です。実際に圧縮した結果は369KBでした。GitHubのリリースページは圧縮済みのものを付けています。1ファイルなので大きくても配布上そこまで問題ではないのですが、やはり軽いほうが気楽ではあります。
5.WEB APIの呼び出し & ハンドリングが楽
呼び出しが楽
以下はChatWorkのチャット一覧を取得するAPIを呼び出しする簡単なサンプルです。他の言語で言うところのimportのようなものは不要で、REPLにすぐに打ち込めます。
write https://api.chatwork.com/v2/rooms [
get [X-ChatWorkToken: "APIキーの値"]
]
getの部分はHTTPメソッドの種類を書きます。その後ろでHTTPリクエストヘッダをkey: value形式で指定します。実際のソースコードではもう少し複雑な書き方をしていますが、APIを試しに呼んでみて結果を見てみたりするのはとても楽です。
呼び出し結果を保存しておける
Redは値もコードもいつでも簡単にファイルに保存できます。ここでは（ChatWorkのデータは載せられないので）サンプルとして京都市オープンデータサイトのAPIを使ったときのレスポンスデータで説明します。以下に実行するコードの例と保存されるファイルの例を記載します。
; リクエストヘッダがないAPIはreadでより簡単に呼べる
url: https://data.city.kyoto.lg.jp/API/action/datastore/search.json?resource_id=f14b57c2-48dd-4aa7-b754-a4f4ac340f2d&limit=3
; レスポンスボディのみ保存
save %response.red read url
; レスポンスステータスコードやヘッダも保存
save %response-info.red read/info url
; レスポンスボディをRedのデータフォーマットに変換して保存
save %response-json.red load/as read url 'json
RedのデータフォーマットはJSONよりも見やすく、そのままRedの関数で絞り込みなどもできるため、よく知らないAPIの中身を見ながら開発する際には便利です2。
また、上記のように結果をファイルとして保存しておくことで、返ってくる結果に対してどのように実装するのかを保存したファイルを見ながら検討できます。分岐に対応するようなレスポンスは残しておくと、後で「この実装ってなんでこうしてたんだっけ・・・」とならずに済み、開発時のイライラの低減に繋がります。
リトライ&待機処理が簡単に書ける
ChatWorkのAPIは5分間で300回までしか呼び出しできない制限があります。制限に達してしまうとステータスコードが429で返るようになり、レスポンスヘッダに入っているX-RateLimit-Resetの時間まで待機した後に再実行が必要になります。下記はこの内容を簡易的に実装したコードです。
; APIを呼ぶコードをブロックとして保持
api-call: [write/info https://api.chatwork.com/v2/rooms [
get [X-ChatWorkToken: "APIキーの値"]
]
]
; 1回目のAPI呼び出し
response: do api-call
; ステータスが429だったら、
if response/1 = 429 [
; X-RateLimit-Resetの時間（UNIX時間） + 1秒後の時間
reset-time: (to-date to-integer response/2/X-RateLimit-Reset) + 0:0:1
; 現在時刻との差だけ待つ（つまり時間になるまで待つ）
wait difference reset-time now/utc
; APIをもう一度実行
response: do api-call
]
とても簡潔に書けますね。実際にはAPI呼び出し時にタイムアウトなどでエラーが発生することがあるので、そのハンドリングが必要です。これはdoをtry関数に変えて、返ってきた結果がerror!型かをチェックすればOKです。
; APIを呼ぶコードをブロックとして保持
api-call: [write/info https://api.chatwork.com/v2/rooms [
get [X-ChatWorkToken: "APIキーの値"]
]
]
; エラー処理用のコードブロック
handling: [if error? response [ "エラー処理をここに書く（ログを書いて終了など）" ]]
; 1回目のAPI呼び出し
response: try api-call
; エラー処理
do handling
; ステータスが429だったら、
if response/1 = 429 [
; X-RateLimit-Resetの時間（UNIX時間） + 1秒後の時間
reset-time: (to-date to-integer response/2/X-RateLimit-Reset) + 0:0:1
; 現在時刻との差だけ待つ（つまり時間になるまで待つ）
wait difference reset-time now/utc
; APIをもう一度実行
response: do api-call
; エラー処理
do handling
]
一般的な言語ではtryは構文ですが、Redでは関数なのでブロックを渡せるというのが非常に柔軟です。
まとめ
いろいろ書きましたがRed楽しいのでみなさんも機会があればぜひ！