rch850 の上澄み

技術的な話題とか、雑談とか。タイトルを上澄みに変えました @ 2020/09/02

ふくもく会その59で RTM API について調べてた

今月のふくもく会 その59 〜黙々勇者 -この開発者が寝TENEEEくせに黙々しすぎる-〜では、Slack の RTM API について調べてました。RTM API、何度書いても手が勝手に RTMP って打っちゃう。

RTM API は WebSocket ベースの API で、ファイアーウォールの内側に立てていてもメッセージ投稿を受信したりできます。このあたりは公式の 必要な Slack API はどれ？に分かりやすくまとまってます。分かりにくい表現があれば、和訳前の原文を読むのがよさそうです。個人的には以下の表現が分かりにくかったです。

  • 「意図的なデータの冗長性が必要」
    • 原文だと "Do you need data feed redundancy" でした。うーん、これでもちょっと分からない。"data feed redundancy" で検索してヒットした Slack API の FAQを読んだら意味が分かりました。Events API だとエンドポイントが落ちてたら終わりだけど、RTM API なら WebSocket クライアントを複数立てることで冗長化できるよということです。
  • 「接続済み WebSocket を介して大量の不要な情報をサーバーに送信してしまうことがあります」
    • WebSocket クライアントに大量のメッセージが飛んでくる、という意味にしては、サーバに送信してしまうという表現がしっくりこないな。と思って原文を読んだら "RTM API sends a lot of unnecessary information to your server" だったので、正解でした。

それで本題の RTM API なんですが、確かに Slack 側へのエンドポイント設定などをしなくても、Slack へのメッセージ送信を受け取り、何かしらリアクションすることができました。Kujaku のような unfurl もできるのかな、と思ったら、なんと link_shared イベントが受け取れない！これは RTM API のイベント比較表にも link_shared イベント自体のドキュメントにも書いてあることです。このあたり、アプリケーションによって Events API を使うか RTM API を使うか決まってくるんだろうなと思いました。あと今年リリースされた Slack apps フレームワークの bolt は RTM API をサポートしていないとのこと。

その他、周りの人の話で気になったものです。