Zapier/IFTTT如何爲不同API提供者實施觸發器和操作？

Question

Zapier/IFTTT如何爲不同API提供者實施觸發器和操作？有沒有通用的方法來做到這一點，或者他們是由個人實施的？

我認爲這個實現是基於REST/Oauth的，即從高層看通用。但對於Zapier/IFTTT，它定義了很多觸發條件，即過濾器。這些條件，過濾器應該針對不同的提供商。相應的實施是在個人還是通用？如果在個人中，則必須有龐大的勞動力。如果在通用中，該怎麼做？

Answer 1

我在Zapier上實現了一些API，所以我認爲我可以在這裏提供至少部分答案。如果不使用webhook，Zapier將檢查來自服務的字段的API響應，該字段的最短名稱也包含字符串「id」。對此字段的更改會導致Zapier觸發任務。這是基於id通常是遞增或隨機的假設。

我不得不通過將id值轉移到另一個字段並在id失敗時寫入不同的值，或者觸發過於頻繁（除以10，然後寫入id可以降低觸發器靈敏度， 例如）。歧義也是一個問題，例如在包含post_id和mesg_id等字段的API響應中。

簡而言之，系統會進行有根據的猜測，但爲了讓它可靠地用於特定服務，在代碼中應該非常明確地指出觸發事件的構成。

Answer 2

Zapier開發人員在這裏 - 簡單的答案是，我們實施每一個！

雖然像OAuth這樣的標準可以更容易地將一些代碼從一個API重用到另一個，但沒有必要了解每個API都有獨特的端點和獨特要求這一事實。一個API的作用不一定適用於另一個API。在內部，我們將盡可能多的流程抽象爲可重用的位，但總是需要一些工作來添加新的API。

Answer 3

PipeThru顯影劑這裏...

有對每個API共同元件，其能夠被重新使用，例如OAuth認證，常見的數據格式（JSON，XML等）。大多數API都爭取實現RESTful。然而，理論符合現實，大多數API都遍佈全球。

每種服務都提供自己的端點，並且對於給定的服務沒有共同商定的端點集合。例如，在CRM軟件中，它不清楚人員，所述人員的筆記，相應的電話號碼，地址以及活動應該如何表示。你提供一個或多個端點嗎？你如何更新每個？你是否提供切記記錄（如公司的人）與記錄或不記錄？每個人都需要具體的該服務知識以及一些數據規範化。

大多數觸發器都涉及檢查新記錄（唯一ID）或更新字段，通常是最後更新時間戳。大多數服務以ISO 8601格式顯示時間戳，這使得解析時間戳變得容易，但不是每個人。 Dropbox實際上提供了一個Delta API端點，您可以向其顯示一個散列值，Dropbox將向您發送從該點開始的新/更改的所有內容。我喜歡在更多API中看到增量和/或活動端點。

底線，整合每個單獨的服務確實需要大量的努力和測試。

我會指出Zapier確實爲其他公司實施了一個API來插入他們的工具。而不是Zapier實現你的API和Zapier輪詢你的數據，你可以發送新的/更新的數據到Zapier觸發他們的一個Zaps。我喜歡把這個想法看成是關於破解的webhooks。這使得Zapier可以支持更多的服務，而無需對每一個服務進行編程。