LINE Bot 系列文 — 什麼是 Webhook?
前言
近期打算寫關於 LINE bot 的系列文章，於是打算先從介紹「Webhook」 寫起。在開始說明 webhook 前，我們先來聊聊一般 API 的運行。
關於 API
API 的全名為 Application Programming Interface。其中，最重要的一個單詞為「Interface」。關於這個「介面」我們可以視為是一種不同設備間的溝通規範，只要符合這個「規範」就能讓兩個不一樣的設備來進行相互溝通。
這邊舉個較常見的例子，以「USB」來說。不知道讀者是否有想過為什麼 USB 的品牌這麼的多，但不同品牌的 USB 卻都可以插入不同電腦的插槽並讓電腦讀取 USB 中的資料。這是因為各品牌的 USB 在製作時，都有符合 USB 的插槽規範。也因為這個規範，才能讓不同品牌的 USB 在不同的電腦中被讀取並寫入資料。
Client-server 端之間的關係
當我們提到 API 時，一般都會先聯想到「主從式架構（Client-server model）」。在該架構中，兩個主要的角色為「Client 端」及「Server 端」。而之間的關係，如下圖所示：
關於「Client」端，我們可以視 client 端為一個「主動」的角色。當 client 端與 server 端之間的連線（Connection）被建立時，第一步皆是由 client 端的請求（Request）所發起，並將該請求送至 server 端。
而「Server」端的部分，我們則可以視 server 端為一個「被動」的角色。當 server 端收到來自 client 端的請求並處理後，就會回傳一個回應（Response）給 client 端。
若要舉個例來說明 client-server 端之間的關係，我們嘗試以「餐廳」做為例子來說明看看。如下圖所示：
以餐廳為例
- 先想像成你是一位客人，服務生來詢問你要點什麼餐。
- 待點餐完成後，服務生將菜單送到廚房。
- 廚房收到菜單的點餐內容後，開始做餐點。
- 廚房將客人所點的餐點完成。
- 餐點完成後，廚房請服務生將餐點送給客人。
- 客人收到服務生所送來的餐點後，開始用餐。
最後，當客人確認收到一開始所點的餐點後，服務生就可以告知廚房說客人以取得餐點，並結束這整個流程。
瀏覽 Google 頁面
或許單以「餐廳」的例子，可能還沒有辦法讓讀者瞭解 API 實際運作的過程。我們舉另外一個實際運作的例子來看看。假設情境為「用 Chrome 的瀏覽器，瀏覽 Google 的頁面」，這邊我們同樣使用 client-server 主從式架構的角度來說明。
- 使用者透過 Chrome 瀏覽器輸入 google.com 的URL，並按 enter 送出。
- 等待 request 從 client 端傳到 server 端。
- 若 google server 端有這個 API 端口，開始處理這個 request 。
- Google server 將資料訊息傳到 response 裡面。
- 等待 response 從 server 端傳到 client 端。
- Client 端接收到 response，並將 google 的畫面呈現給使用者看。
最後，當 client 端確認收到一開始 request 所想取得的資料後，就會告知 server 端確實有收到這筆資料並結束整個 connection。
順帶一提，由於「Client端」與「Server端」之間是透過 HTTP 協定來進行連線。等同於任何可以使用 HTTP 協定的設備，我們皆能透過 API 來讓不同的設備來進行相互溝通。
關於 Webhook
在介紹完基本的 API 運作流程後，並開始解釋 webhook 為何物前，我們先舉個情境再接續說明，應該能讓讀者更加瞭解 webhook 的定義及運作。讓我們延續使用剛剛的餐廳案例，但這次的角色將轉變成「餐廳」與「外送員」。
餐廳 V.S. 外送員
如果說，今天客戶使用餐飲外送服務商所製作的 APP 來進行餐點下訂的動作時，餐廳就會接收到訂單並開始製作餐點。那麼外送員要怎麼知道餐廳什麼時候做好餐點，並在餐點完成時去餐廳取餐，接續送到客戶的手上呢？
或許，外送員可以使用一種名為「輪詢(Polling)」的方式來進行確認。其行為就是讓身為 client 端的外送員定期向 server 端的餐廳去進行「餐點是否完成？」的確認。這部分，如果使用 client-server 主從式架構來表示，大概會變成這樣。
你可能會覺得這個方式不錯，只要服務員想要確認餐點好了沒，打通電話就可以知道狀況。
但換個角度想，這種做法若是餐點確認的間隔時間太短，不僅會造成 server 端的負荷。若間隔時間太長，也會同時造成收到的資訊有不即時的問題發生。
這邊的「即時」是指若我們每隔 30 秒發送一次 request，但餐點卻是在這 30 秒之間就處理好，這中間的時間差距就導致「資訊不即時」的問題發生。
而且，當服務員不停的打電話跟餐廳確認餐點做好沒，也有可能讓餐廳憤而決定取消與餐飲外送服務商的合作。（笑
那有沒有更好的方式呢？
其實，反過來思考就行了。餐廳如果能主動向外送員說：「餐點做好了。」那是不是外送員就不用定期跟餐廳來做確認的動作，餐廳也不用因為外送員的不斷確認而讓心情受到影響，讓整個處理餐點的效率變差。而這個方式也就是這篇文章的重點 「webhook」 所能做到的事情。
關於 webhook 在這個例子的運行情境。如下圖所示：
「Webhook」 的重點就在於餐廳能「主動」去聯繫外送員。也就是說，身為外送員的 client 端需要額外開啟一個 API 的端口。當餐點完成時，身為餐廳的 server 端就可以藉由這個 API 來主動告知外送員餐點已經做好了。
這時，外送員將由原本的「主動方」變成「被動方」，而這樣的處理方式就是「webhook」所能做到的。
在 LINE bot 上的 webhook
對我們開發者而言，如果要在 LINE Bot 上進行開發則需要遵守 LINE 官方所提供的「Messaging API」的規範來進行開發。
其規範中有提到在 LINE BOT 的設計主要分有三個角色，分別是：
- 用戶：藉由 LINE APP 來發送訊息的使用者。
- LINE Platform： LINE 官方用來傳遞「用戶」及「Bot server」資訊的中介 server。
- Bot server：用來開發 LINE Bot 的 server。
而這三個角色之間的關係，我們可以用一張圖來說明它們之間的關係。
用戶發送的訊息能藉由 LINE Platform 來向 Bot server 來進行傳遞。而 Bot server 也能主動的向用戶藉由 LINE Platform 來進行推播的動作。
而「webhook」的部分則是設置在 LINE Platform 與 Bot server 之間。能藉由 Messaging API 來針對不同的 webhook event 來進行相互溝通。
小結
對於「webhook」，簡單來說就是不管身為 client 端或 server 端，任一端都要能有開 API 的能力，因為它是一個運用在 server 與 server 之間的概念。當兩端都能同時擔任「發送方」及「接收方」時，就能避免掉「輪詢(Polling)」所造成的問題。
這篇文章會以 API 說明做為開頭是因為 webhook 是 API 眾多運行方式的其中一種。而 LINE Bot 的開發又需要使用到 webhook。若是讀者還不太了解 API 的運行方式，可能就不太能理解 webhook 會被運用在 LINE bot 上開發的原因。