特定のタスクのために API をコールする

学習の目的

この単元を完了すると、次のことができるようになります。

コア Slack API とその目的を特定する。
SDK を使用するよりも直接 API コールを使用するほうが適している状況を特定する。

直接 API コールが適している場合

ソフトウェア開発キット (SDK) を使用するのではなく、API を直接コールしたほうがよいのはどのような場合でしょうか?

次のような場合には直接 API コールを選択します。

完了すべきタスクが具体的で 1 つだけである。
イベントをリスンしたりインタラクションを処理したりする必要がない。
連動関係を最小限に抑え、コードを軽量にしたい。
すでにシステムがあり、そこから Slack にデータを転送するだけでよい。
独自のアーキテクチャを持つ既存のアプリケーションに Slack を統合する必要がある。

たとえば、監視システムがあり、サーバーが停止したときに Slack にアラートを投稿する必要があるとします。ボタンやモーダル、ワークフローは不要で、メッセージを送信するためのシンプルな HTTP POST のみが必要です。これは直接 API コールに最適なユースケースです。

コア Slack Web API を知る

Web API は Slack の中核的な HTTP ベースのインターフェースです。Slack でデータの読み取り、書き込み、更新を行うための 200 以上の方法が提供されています。Web API は Slack プラットフォームの基盤であり、ほぼすべての Slack アプリで使用されています。

Web API を使用して何ができるのでしょうか?

直接 HTTP コールを使用して次のことを実行できます。

チャンネルにメッセージを投稿する (chat.postMessage)。
チャンネルを作成、管理する (conversations.create、conversations.archive)。
ユーザープロファイルを更新する (users.profile.set)。
ファイルをアップロードする (files.upload)。
メッセージ履歴を取得する (conversations.history)。
ワークスペース設定を管理する (その他の何百ものメソッド)。

使用する状況: 完全なアプリを作成せずに、1 回限りのアクションを実行したり、既存のワークフローに Slack を統合したりする必要があるすべての状況。CI/CD パイプラインでビルド結果を投稿するなら、 Web API を使用します。CRM で日次サマリーを送信する場合も、 Web API を使用します。分析ツールでレポートを共有する場合も、 Web API を使用します。

Web API の利点はそのシンプルさにあります。Web API は単なる HTTP 要求であるためです。curl、Python の requests ライブラリ、またはあらゆる言語のあらゆる HTTP クライアントを使用できます。フレームワークは必要ありません。

イベント API を使用してリスンおよび応答する

Slack のイベントに応答する必要があるが、SDK のフル機能は必要ないという場合は、イベント API を使用すれば、特定のイベントに登録し、自分が管理する HTTP エンドポイントでそれを受信できます。

そのしくみは次のとおりです。

目的のイベントに登録する (message.channels や reaction_added など)。
Slack がイベントデータを送信できる公開 URL を指定します。
イベント発生時に Slack がイベントをエンドポイントに転送します。
必要に応じた処理を行います。

使用する状況: HTTP Webhook を処理できる既存の Web サービスがあり、特定の Slack アクティビティに対応したい場合。たとえば、センチメント分析のために商品名のすべてのメンションをログに記録する場合や、特定のリアクションが現れたときにワークフローをトリガーする場合などです。

イベント API は、SDK ベースの完全なアプリを実行するよりも軽量ですが、要求の検証、イベントの解析、3 秒以内の確認要件を自分で処理する必要があります。

ソケットモードを使用してアプリを保護する

そこで賢い代替策になるのがソケットモードです。HTTP URL を公開する代わりに WebSocket 接続でイベントを受信できます。ソケットモードは、Slack との通信用に静的 HTTP エンドポイントを公開したくない場合に役立ちます。

使用する状況: 開発中、または会社のファイアウォールの背後にあるなどエンドポイントを公開するのが困難な環境でアプリを実行している場合。ソケットモードを使用すれば、API を直接コールする場合であっても、インフラストラクチャの複雑さに悩まされることなくイベントを受信できます。

特定のニーズに対する専用 API

Slack では、特定のユースケース向けに設計されたいくつかの専用 API が提供されています。それについて知っておくことで、大幅に時間を節約できる場合があります。

管理 API

ワークスペース管理タスクに特化した Web API メソッドのサブセット。次のような用途に使用します。

ユーザーのオンボーディングを自動化する。
大規模なワークスペース設定を管理する。
複数のチームにわたって一括操作を実行する。

使用する状況: IT 管理者向けの内部ツールを作成する場合や、ID 管理システムに Slack のプロビジョニングを統合する場合。

SCIM API

SCIM 標準に従ってユーザーのプロビジョニングと管理を行うために設計されています。

使用する状況: Slack を Okta、Azure AD、OneLogin などのエンタープライズ ID プロバイダーに接続して、ユーザーライフサイクルの自動管理を行う場合。

監査ログ API

この API を使用すると、セキュリティとコンプライアンスのための詳細な監査ログにアクセスできます。

使用する状況: セキュリティ情報およびイベント管理 (SIEM) ツールを作成する場合や、すべての Slack アクティビティを追跡する必要があるコンプライアンスレポートシステムを作成する場合。

Slack ステータス API

この API は、インシデント、停止、メンテナンスなど、Slack サービスの健全性を監視します。

使用する状況: サードパーティサービスの健全性を表示する内部ダッシュボードを作成する場合、または Slack に問題が発生したときの対応を自動化する場合。slack-status.com/feed/atom で Atom または RSS フィードに登録して、自動的に更新情報を受信することもできます。

タスクに適した API を選択する

判断のための簡単なガイドを次に示します。

メッセージの投稿やアクションの実行が必要な場合は、 Web API を使用します。
Slack イベントに対応する場合は、 イベント API またはソケットモードを使用します。
大規模にユーザーを管理する場合は、 管理 API または SCIM API を使用します。
セキュリティツールまたはコンプライアンスツールを作成する場合は、 監査ログ API を使用します。
Slack のアクティビティを監視する場合は、 ステータス API を使用します。

重要なのは、具体的なタスクをその目的のために設計された API と対応付けることです。これにより実装をシンプルで焦点を絞ったものに保つことができます。

直接 API コールの利点

Slack API を直接コールすると、必要な機能のみが提供され、余分な機能は提供されません。大きなフレームワークをインポートしたり新しい抽象化を学習したりするのではなく、適切に文書化されているエンドポイントに対して HTTP 要求を実行するだけです。コードは軽量で、連動関係は最小限で、ソリューションは単純です。

通知の投稿、データの同期、管理作業の自動化などの多くのタスクで、このシンプルさは目的に適しています。

まとめ

特定の限定されたタスクがあり、SDK のフル機能は必要ない場合に Slack への直接 API コールを使用します。Web API はほとんどの操作の基盤となり、管理 API、SCIM API、監査ログ API、ステータス API などの専用 API によって特定のユースケースに対応できます。インテグレーションがシンプルでニーズが明確な場合には、適切に作成された HTTP 要求が最適であることがあります。

予想時間

トピック

ヘルプをお探しですか?

Slack のリソース