zapier ifttt 有何區別？

01-29

原文發表於少數派：IFTTT vs. Zapier：同樣是連接不同的網路服務，它們有什麼區別？
作者：王掌柜
------
歡迎大家閱讀王掌柜帶你玩轉 Zapier 系列，這個系列將持續更新，本篇是這個系列第三篇 Zapier 和 IFTTT 的對比。

第一篇：《王掌柜帶你玩轉 Zapier - 影評自動化》

第二篇：《王掌柜帶你玩轉 Zapier - 閱讀自動化》

IFTTT 和 Zapier 是什麼

IFTTT 的理念就像它的名字 If This Then That ，可以將兩個不同的服務關聯到一起，最典型的例子就是「如果明天下雨，那麼就提醒我帶雨傘」，在這個設定下，IFTTT 會定時查詢第二天的天氣預報，如果天氣預報返回的結果是第二天下雨，那麼 IFTTT 就會給我設置的手機號發送簡訊，通知我第二天出門別忘了帶傘。
關聯閱讀：《觸發你的智能生活：IFTTT 入門》
Zapier 的基本功能與 IFTTT 類似，但它是 IFTTT 的增強版。不同於 IFTTT 只支持串聯兩個服務，Zapier 支持串聯多個服務，讓你可以建立一套有更複雜需求的工作流。Zapier 支持大量的高級服務，具備極高的專業性和企業級應用場景。價格上，IFTTT 大部分功能都是免費的，而 Zapier 基礎功能相對簡單並且有運行次數限制，很多高級功能都需要付費。目前 Zapier 在國外科技圈收到大力追捧和推薦，今天王掌柜就帶著大家玩轉 Zapier，做一次 IFTTT vs. Zapier。

Service 數量對比

Service 的數量決定了這個服務的擴展性。截止到目前 IFTTT 大約支持 44 個分類里的 1120 個 Service，而 Zapier 目前支持約 903 個 Service。
IFTTT 和 Zapier 都針對互聯網上比較常見的 Service 提供了支持，數量上，IFTTT 領先，但是 Zapier 是付費服務，這就決定了他們對付費用戶提供了更定製化的支持，比如 Premium 分類下的的 Service ，相比免費的 Service 更專業。
我們看到上圖中，支持的服務包括 Amazon EC2、Amazon S3、AWS Lambda、Amazon SNS、Evernote Business 等，其實還有很多比如 Paypal、MySQL、Airtable、Facebook Pages、Flickr、LinkedIn、MailChimp、MeisterTask、Moxtra 等眾多優質服務，這些服務之所以稱為 Premium 是因為官方維護這些應用所需成本較高，或者開發這些服務成本高，所以在 Zapier 只有付費用戶才能使用。
舉一個簡單列子說明一下，成本問題，比如我們要使用 Paypal 的 Service ，Zapier 實現他的方式不是傳統的輪詢調用 API 方式，他是採用 Webhook 方式，當 Paypal 完成一項任務後，會主動推送信息到 Zapier 的 Webhook，這種情況下，我們的 Zapier 才會進行相應的動作。

Webhook 不同於我們已知的 API ，API 是 Zapier 通過類似輪詢的方式主動抓去數據來啟動觸發器，而 Webhook 是被動服務，被動服務是指當 Service 在完成一件事情後，主動請求 Zapier，將結果告知 Zapier，這種 webhook 在粘合劑服務中，算是代價比較高的服務且，支持起來有一定難度，一般只有付費用戶才能享用。

小結

調試靈活性對比
變數：Zapier 可以直接顯示變數值，IFTTT 只能顯示名稱
Zapier 設置任務流中使用「變數」的時候，除了通過變數名稱猜測其含義，它還可以在變數列表裡清晰的展顯示出變數對應的值，而 IFTTT 只能通過變數名稱來猜測其對應的內容。
在使用 IFTTT 服務的時候，通常我們先有一個想法，比如「將 Pocket 中的一篇文章，打上標記後，自動保存到 Evernote 中] ，我們最優先的做法是去 IFTTT 找一下是否有人共享了類似的 Applet（我們將 IFTTT 每個任務流稱作一個 Applet），如果有的話，我們直接激活該 Applet 就能使用了。但是，難免我們需要一些定製化的修改，這時候就必須進入到 IFTTT 的 Applet 編輯界面進行調試（所謂調試就是修改輸入和輸出，讓服務按照我們的想法去執行），那麼這個調試過程在 IFTTT 中是否友好呢，我們來看下圖。
我們看一下圖中箭頭標註內容，代表的是存入 Evernote 時使用 Pocket 那篇要保存的文章的部分欄位（對應的內容，比如標題比如 URL 鏈接），我們看到在圖中，IFTTT 是用類似變數（編程中的名字，用一個變數名來抽象化我們實際用到的內容）的方式來實現，對於沒有編程經驗的菜鳥來說，這幾乎很難能夠理解。我們再來看一下 Zapier 是如何調試的。
上圖中，我們同樣是實現將 Pocket 中內容保存到 Evernote 中，我們看箭頭所指的標註內容，Zapier 也是用變數方式來代表我們要使用的內容，但是變數的後邊還給出了實際的內容，這樣看起來即使你不懂變數是什麼內容，也能夠知道哪個欄位才是你想要的。這樣調試的話是不是感覺更簡單和直接呢？應該是顯而易見了。
小結

運行結果：Zapier 可以直接調試任務流、IFTTT 只能等待系統自動調試

Zapier 可以在後台很方便的執行一個任務流從而觀察執行結果，而在 IFTTT 中每次只能等待系統的輪詢時間，並且這個時間也是不固定的。
調試任務流，除了變數要夠清晰之外，查看運行結果也是非常必要的一環，能夠很方便的查看運行結果對調試來說是事半功倍的事，我們分別看看 IFTTT 和 Zapier 是如何表現的吧。
在 IFTTT 中創建好任務流，如果想查看執行結果，必須要等待自動輪詢（附錄中可以查看輪詢的相關說明）完成才可以，而這個時間可能是 1-3 分鐘，也可能是 10-20 分鐘，所以說時間是不確定的，這為我們調試任務流帶來了很大的麻煩。
我們再來看看 Zapier 是如何做的呢，在 Zapier 中每一個創建好的任務流，我們都可以去 Zapier 後台，找到要執行的 Zap，選擇 Run，他就會立即執行，怎麼樣，非常便利吧，簡直是不能再好用了。

Zap，在 Zapier 中創建的每個任務流稱為一個 Zap。

小結
多 Service 協作：Zapier 支持串聯多個服務，IFTTT 只能串聯兩個服務
Zapier 實現「如果 A 發生了事情 1，那麼讓 B 發生事情 2，再讓 C 發生事情 3，最後讓 D 發生事情 4」這樣的任務流只需要創建一個任務流；而 IFTTT 若實現類似服務，至少要創建三個任務流。
在 IFTTT 中，我們只能設置「如果 A 發生了事情 1，我們就讓 B 發生事情 2」，這裡只能涉及兩個服務，但是在實際使用環境中，有些任務流可能需要多個 Service 協作才能完成，恰好它的小夥伴 Zapier 支持一個任務流多個服務協作。我們還是舉「影評自動化」這個例子說明一下。

在本系列的第一篇文章《王掌柜帶你玩轉 Zapier - 影評自動化》中，我們的任務流需要完成以下三件事：

當有一篇新文章存入 Evernote 的「013@電影筆記」文件夾下的時候（代表我們完成了影評的編寫）。

在 Todoist 中的找到和 Evernote 筆記同名的任務，並且設置任務為已完成（代表「影評提醒」這個任務已經完成了）。

在 Twitter 中創建一條消息，將 Evernote 中的影評筆記發布出去。

我們看到這個例子中就涉及到了 3 個 Service ，分別是 Evernote、Todoist、Twitter ，在 Zapier 中我們很容易在同一個任務流中創建多個 Service 協作（實現方式可以翻看上一期文章），而在 IFTTT 中要想實現多服務協作，我們需要至少創建兩個任務流才可以。
小結

單 Service 多賬號：Zapier 支持多賬號，IFTTT 只支持單賬號

Zapier 可以為每個 Service 設置多個不同賬戶，從而提升任務流的靈活性，而 IFTTT 每個 Service 只支持一個賬戶。
如果一個團隊使用或者針對同一個 Service 有多個帳戶在使用的情況，「每個 Service 支持多套賬戶」的功能就非常有必要了，這樣可以做出更複雜的任務流，我們還是舉例說明。
任務流 1

我要求部門員工每天在 Trello 里在當天完成（或未完成）的任務卡片里寫評論，算作當天的工作日誌。

然後我為了不用一個一個的翻看他們的評論，我在 Zapier 中設置一個任務流，觸發器就是每當有人在指定的 Board 中評論了一個 Card，Action 是將評論內容寫入以「當天日期」命名的文章里保存到 Evernote 中。

這樣我就可以每天下班前打開 Evernote 中的這篇文章查看所有人的工作日誌了。

觸發器：設置一個觸發器，Zapier 會輪詢檢查觸發器條件，當條件滿足，代表觸發器被成功觸發。
Action：在 Zapier 中，任務流中的每一步我們稱之為一個 Action。

任務流 2

我在「少數派的選題箱」中看到了一篇題目或者我自己創建了一篇題目（ Trello 里的 Board），我覺得自己可以寫，於是我把任務卡片移動到「在寫」 LIst 里，我就開始去寫。

為了激勵自己，並且提醒我有未完成的稿件，於是在 Zapier 里創建了一個任務流，觸發器就是「我將一個任務卡片移動到在寫 List 里」，Action 是「Zapier 在 Todoist 里自動創建一個任務」，提醒我要完成這篇稿件。

以上兩個任務流，都用到了 Trello ，但是問題是我公司用的 Trello 和少數派選題用的 Trello 是兩個賬戶，此時「每個 Service 可以配置多套賬戶」就起到關鍵作用了，我可以設置兩個不同的賬戶，在創建這兩個任務流的時候，選擇不同的賬戶即可，非常方便。

那麼他的對手 IFTTT 表現如何呢？
IFTTT 目前並不支持一個 Service 對應多個賬戶，但是在它的高級版中提到了「可以與團隊深度合作」，也許能支持多賬戶，但是這個高級版的的費用是 $499/year，估計一般情況也不會有人使用，我們也就無從比較了。
小結

其它易用性對比

從創建任務流這個基礎需求角度看，IFTTT 和 Zapier 都沒有什麼問題，對於有一定英文閱讀基礎的人來說，照著提示就可以完成配置，但是作為後期之秀的 Zapier，當然是有一些差異化的表現，它提供了幾個重要特性，提高了易用性，特別是對一些大型的企業級任務流比較有幫助，下邊針對幾個非常有特點的特性，我們都拿出來和 IFTTT 對比一下。
Zapier 支持全局存儲變數，並且可以在不同工作流之間共享
Zapier 最強大的功能之一就是將數據存儲在全局變數中，這種變數可以在不同的 zap 之間共享。這被稱為 Storage by Zapier ，並且本質上它允許您存儲小值（例如，文本字元串）以便在其它 zap 中重用。

Zap：在 Zapier 中創建的每個任務流稱為一個 Zap。

它有多種存儲類型：基本值（可以設置和讀取，就像工作流中的變數一樣），還有子值和列表。對於每種類型的存儲，都有刪除值和修改它們的操作：可以增加一個數值，一個值可以被刪除，或者，如果你正在處理一個列表，一個值可以從開始或結束時彈出的列表。這為Web自動化提供了令人難以置信的可能性，我們用一個打卡事件來舉例說明。
我們天都會跑步，我想記錄我每次跑步的時間，於是我設置以下任務流：

當我開始跑步的時候，執行 Workflow 通過 Zapier 的 Webhook，我們記錄一個當前的時間戳存儲在變數中，變數的 Key 為 playStartTime （運動開始時間）。

當我跑步結束的時候，執行 Workflow 通過 Zapier 的 Webhook，獲取變數 playStartTime ，計算一個時間差，獲取到本次跑步時長，我將時間存入到 Evernote 中以作記錄。

這樣我只需要每次跑步開始的時候打開手機執行一下 Workflow，跑步完成的時候在執行一下 Workflow ，這條記錄時間就被存儲下來了。

小結
Zapier 支持自動重新執行失敗的任務流
任務流執行失敗了沒關係，Zapier 提供了失敗重新執行的特性，保證我們每一個任務流的準確無誤。
此特性對於任務執行成功率有很大的保證作用，無論是 Zapier 還是 IFTTT ，他們都是通過 API 鏈接一個或者多個 Service，這裡有一些不確定性，比如當時服務網路抖動，比如當時某一個 Service 出現 Bug ，這些事情是無法避免的。
那麼這個特性就會在我們遇到一個任務流執行失敗了的時候，自動重新執行它，一直到他能夠正確運行為止，這個特性就是保證了我們任務的正確返回，保證我們不會有因為其它原因漏掉的執行結果。但是， Zapier 中享受此服務需要至少 $50／月 ，這個絕對是硬傷，如果你不是對任務流要求百分百必須準確執行的話，可以不考慮使用此特性。
小結
IFTTT 有 iOS 原生客戶端，Zapier 沒有
IFTTT 提供了 iOS 原生客戶端，從而打通了系統應用和 Service 之間的壁壘，Zapier 沒有 iOS 客戶端，但是通過 Workflow + Webhook 也可以曲線救國。

IFTTT 提供了 iOS 客戶端，通過客戶端我們可以處理很多 iOS 原生服務，比如「 iPhone 有新的照片了」，比如「新建了提醒事項」，有了這個原生的客戶端，IFTTT 就將原生服務和其它 Service 打通了，我們再舉個例子。
我的主力手機是 iPhone ，我用手機拍攝的照片都會默認存在 iCloud 中，但是我不是很放心 iCloud 服務，所以我想同時把照片同步到 Dropbox 中，於是我在 IFTTT 中設置任務流，每當 iPhone 有新的照片時，自動同步到 Dropbox ，但是有一個前提，iPhone 照片不是一個 Service，我們就需要安裝 IFTTT 的客戶端，每天晚上運行一次 IFTTT 客戶端，客戶端會自動發現新照片，並且同步到 Dropbox ，當然這個動作你也可以不定期的打開一次 IFTTT 即可。
那麼 IFTTT 的競爭對手 Zapier 表現如何呢？
Zapier 並沒有提供 iOS 客戶端，當然也就無法像 IFTTT 那樣實現「影評自動化」例子中的功能了，但是 Zapier 支持 Webhook ，通過 Webhook 我們利用 iOS 上的應用 Workflow ，每天執行一下 Wrokflow 腳本，Workflow 會選擇出當天的照片，通過調用 Zapier 的 Webhook ，將照片上傳到 Dropbox ，這樣一樣實現了上面提到這個例子的功能。
小結

費用情況對比

IFTTT 大部分功能都是免費的，而 Zapier 基礎功能相對簡單，如若使用上邊提到的很多特性都需要付費才能享用。
IFTTT
Zapier

總結

通過以上 IFTTT vs. Zapier 我們可以看到，對於這兩個粘合劑服務，各自都有自己的特點：

IFTTT ，老牌便宜例子多，基本上常用的任務流都會被涵蓋，網友可以隨意上傳自己製作的 Applet 供大家修改和使用。

Zapier，IFTTT 優秀的模仿者，在實現了 IFTTT 的大多數功能基礎上，對任務流的創建和調試做了很多優化，使用起來更加人性化也更簡單；同時，Zapier 還對企業級任務流有著先天的優勢，比如他的多 Service 協作支持 和 單 Service 多賬戶支持，都為企業級應用和專業用戶提供了很好的支持。

以上兩個服務都是互聯網上最優的粘合劑服務，那麼作為一個用戶我們該如何選擇他們，以及如何看待他們的費用問題，我想大家還是從各自的實際角度出發，這裡王掌柜給出幾個建議供大家參考：

如果你是一個新手入門，沒有那麼多任務流需求，而且夠用就行，建議考慮 IFTTT，簡單夠用，上手入門容易。

如果你是一個老江湖，對與任務流有著複雜的需求，並且隨時有著各種各樣的想法，想調試和實現，建議考慮 Zapier，他的調試和易用性更高，隨時滿足你的想法。

如果你想在企業或團隊中應用，讓團隊的小夥伴們都能夠享受到任務流帶來的便利，建議考慮 Zapier ，畢竟他針對企業級任務流做了很多優化，這些是 IFTTT 沒有也做不到的。

附錄
輪詢，IFTTT 和 Zapier 這樣的粘合劑服務，通常採用輪詢的方式去執行用戶設置好的任務流，這種方式也叫作主動執行，這樣做的話，伺服器負載高，運行成本高，但是簡單易用維護成本也低。
與之對應的還有一種方式叫被動執行，被動執行是指當用戶設置好了任務流，每個 Service 在完成某事的時候會主動通知伺服器（伺服器屬於被動執行）來讓伺服器知道 A 完成了事情 1，準備去讓 B 完成事情 2 吧。這樣做的話伺服器成本低，負載也低，但是開發和維護成本較高。

前者收費但質量好。
其他的差別不重要。

推薦閱讀：