まずは基本から始めましょう。APIとは何でしょうか？ 簡単に言えば、APIとは、2つのソフトウェアプログラムが互いに通信し、データを共有するための仕組みです。人間が共通の言語を通じて情報を共有するように、コンピュータも同様に情報を共有するのです。
人生において、物事には正しいやり方と間違ったやり方があるものです。ソフトウェア開発も例外ではありません。Rockの統合において、間違った方法で実装された場合にしばしば見られる問題の一つは、Rock API（データ共有言語）の使い方です。例えば、ファイルキャビネットから大量のファイルを取り出したいとしましょう。その場合、あなたは次のうちどちらを選びますか：
- ファイルキャビネットまで歩いて行ってください。
- 一番上の引き出しを開けてください。
- 1つのファイルを取得します。
- キャビネットを閉めてください。
- 自分のデスクまで歩いて戻ってください。
- そのファイルを机の上に置いてください。
- その後、必要なファイルごとに手順1～6を繰り返すのですか？
もちろん違います！しかし、多くの統合ツールはまさにそのようにRockに処理を行っています。それよりも、ファイルキャビネットまで一度だけ行き、必要なファイルをすべてまとめて取り出し、すぐに自分のデスクに戻るほうがはるかに賢明です。これをAPIへの「リクエストのバッチ処理」と呼びます。そうしない場合は、APIの不正利用とみなされる可能性があります。
簡単そうに聞こえますよね？ しかし、この方法でAPIを誤用している統合がどれほど多いかを知れば、きっと驚くでしょう。この件について尋ねると、サービスプロバイダーからは「Rockが提供するAPIを使っているだけです」といった返答が返ってきます。確かに、当社では単一の検索呼び出しを提供していますが、それらはあくまで「1つのファイル」に関する情報を取得するためだけに特別に設計されたものです。大量のデータが必要な場合は、一度に複数のレコードを返す呼び出しを使用する必要があります。 Rockにはそのような呼び出しが多数用意されていますが、非常に特殊な要件がある場合は、場合によっては「目的特化型」のカスタムエンドポイントを構築する必要があるかもしれません（Rockではこれも可能です）。
実際の事例を見てみましょう。当社のコンサルティング業務において、Rockとの連携を希望しているシステムを利用している中規模の教会に出会いました。このサービスプロバイダーは、RockのAPIを使用して、2時間ごとにRockからデータを取得していました。
以下は、彼らのRockサーバーへの全トラフィックを示すグラフです。各棒グラフは1日分を表しており、色はインターネット上の1つのアドレスを表しています。まず最初に疑問に思うのは、「青い棒グラフは何だろう？」ということでしょう。きっと教会のインターネット接続に違いない、ですよね？ スタッフ全員によるトラフィックの多さでしょうか？ いえ、違います。これは、Rockへの全トラフィックの86％を占めている、不適切に作成されたサードパーティ製統合ツールによるものです。最初の棒グラフが日曜日であることに注目してください。このトラフィックは日曜日のチェックインにどのような影響を与えているのでしょうか？ この具体的なケースでは、この統合ツールのために教会はサーバーインフラのアップグレードを余儀なくされ、予期していなかったコストが発生しました。
もちろん、すべての統合が悪いというわけではありません。実際、うまく実践している組織もたくさんあります。では、その違いをどう見分ければよいのでしょうか？ ここにいくつかのアドバイスをご紹介します：
- My Well Gateway や Pushpay Plugin のような人気のある連携機能であれば、おそらく問題はないでしょう（どちらの例も、Rock API を非常にうまく活用しています）。人気のある連携機能は多くの組織によって検証されており、潜在的な問題のほとんどは Spark やその他の Rock パートナーによってすでに発見されているはずです。
- 小規模なスタジオやニッチなパートナーによる統合については、Triumphやその他のRockパートナーなど、Rockに関する深い知識を持つ第三者の技術専門家によって評価されるべきです。
テクノロジーの世界に足を踏み入れると、成功を収めるためには多くの責任を担うことになります。Triumphでは、皆様がこうした難局を乗り越え、確実に成功を収められるようサポートいたします。何かお役に立てることがあれば、ぜひお気軽にお問い合わせください。