Zapier/IFTTT は、さまざまな API プロバイダーのトリガーとアクションをどのように実装していますか? それを行うための一般的なアプローチはありますか、それとも個別に実装されていますか?
実装はREST / Oauthに基づいていると思います。これは、高レベルから一般的なものです。しかし、Zapier/IFTTT の場合、多くのトリガー条件、フィルターが定義されています。これらの条件、フィルターは、異なるプロバイダーに固有である必要があります。対応する実装は個別ですか、それとも汎用ですか? 個人の場合、膨大な労働力が必要です。一般的な場合、それを行う方法は？
PipeThru 開発者はこちら...
各 API には、OAuth 認証、一般的なデータ形式 (JSON、XML など) など、再利用できる共通の要素があります。ほとんどの API は、RESTful な実装を目指しています。ただし、理論は現実に対応しており、ほとんどの API はいたるところにあります。
各サービスは独自のエンドポイントを提供し、特定のサービスに適した、一般的に合意された一連のエンドポイントはありません。たとえば、CRM ソフトウェアでは、人物、その人物に関するメモ、対応する電話番号、住所、および活動をどのように表現すべきかが明確ではありません。提供するエンドポイントは 1 つですか、複数ですか? それぞれどのように更新しますか？接線記録 (個人の会社名など) を記録と共に提供しますか? それぞれに、そのサービスに関する特定の知識と、データの正規化が必要です。
ほとんどのトリガーには、新しいレコード (一意の ID) または更新されたフィールド (ほとんどの場合、最終更新のタイムスタンプ) のチェックが含まれます。ほとんどのサービスは、タイムスタンプの解析を容易にする ISO 8601 形式でタイムスタンプを表示しますが、すべてのサービスではそうではありません。Dropbox は、ハッシュ値を提示できるデルタ API エンドポイントを実際に提供しており、Dropbox はその時点からのすべての新規/変更を送信します。より多くの API でデルタ エンドポイントやアクティビティ エンドポイントを見るのが大好きです。
要するに、個々のサービスを統合するには、かなりの労力とテストが必要です。
Zapier は、他の企業が自社のツールにプラグインするための API を実装したことを指摘しておきます。Zapier が API を実装し、Zapier がデータをポーリングする代わりに、新しい/更新されたデータを Zapier に送信して、Zap の 1 つをトリガーすることができます。私はこれをクラックの Webhook のように考えるのが好きです。これにより、Zapier は、それぞれをプログラムすることなく、より多くのサービスをサポートできます。
Zapier 開発者はこちら - 簡単に言えば、それぞれを実装しています!
OAuth のような標準により、ある API から別の API へのコードの一部の再利用が容易になりますが、各 API には固有のエンドポイントと固有の要件があるという事実を回避することはできません。ある API で機能するものが別の API でも機能するとは限りません。内部的には、再利用可能なビットにできる限り多くのプロセスを抽象化しましたが、新しい API を追加するには常に何らかの作業が必要です。