【技術筆記】「API vs Webhook」他們之間有什麼區別,什麼情況下會使用到他們?


【技術筆記】「API vs Webhook」他們之間有什麼區別,什麼情況下會使用到他們?
通信是數字時代的關鍵驅動力。作為人類,我們希望技術能夠幫助我們更快,更輕鬆地與更多人交流。但是,為了做到這一點,我們必須首先找到一種使技術相互交流的方法-這就是APIwebhooks發揮作用的地方。
WebhooksAPI都有助於在兩個應用程序之間同步和中繼數據。但是,兩者的做法不同,因此它們的用途略有不同。為了消除兩者之間的混淆,讓我們看一下WebhookAPI的區別,以及每種情況最適合的情況。




API vs Webhook:簡單術語上的差異
簡而言之,API會在您要求的時候去執行操作,而Webhook會在滿足特定條件或發生場景時自行執行操作。我們可以從服務器使用API​​example.com通信。通過該通信,API可以列出(List),創建(Create),編輯(Edit)或刪除(Delete)項目。不過,需要給API說明。
另一方面,Webhooks是從example.com到服務器的自動調用。當example.com上發生特定事件時,將觸發這些調用。例如,如果新用戶在example.com上註冊,則自動呼叫可以配置為要求服務器發送歡迎電子郵件。



API介紹:Application Programming Interface
什麼是APIWhat is an API?
API代表應用程序編程接口(API stands for Application Programming Interface.)API是應用程序和平台通過通用通信方法與其他應用程序和平台連接的一種方式。為了使API能夠正常工作,需要一個數據請求,然後是對該請求的響應。數據通常以JSON之類的格式傳遞。
API往往是許多現有軟件和工具所依賴的框架。例如,創建Twitter趨勢報告的應用程序可以依靠APITwitter連續獲取最新數據。大多數大型應用程序具有多個API,它們與它們集成在一起以擴展其服務範圍,如下所示。
 
何時使用APIWhen to Use an API?
當您知道數據將不斷變化時,API的運行會異常出色。如果您需要的數據相對停滯,那麼使用API​​毫無用處。例如,如果您是一家電子商務商店,必須定期更新其運輸和跟踪數據,那麼您將不斷提出要求。每次輪詢API時,您都會擁有新數據。如果您的數據沒有經常更新,則無法保證另一端將為您準備好數據。發生這種情況時,您只是在浪費資源。但是,如果您設置使用API​​,則可以設置通話限制,這將限制您在設置的時間段內進行的通話次數。某些應用程序甚至限制了您從一開始就進行的通話次數,以減少其資源消耗。
  
現實生活中的API示例
就像我們上面提到的,API無處不在。根據ProgrammableWeb的最新結果,當前有17,000多個現有API。在下面,您將找到一些利用API來使其工具起作用的工具:
1.         作為API優先的CMSButterCMS擁有自己的REST API,該API具有可預測的,面向資源的URL,並使用HTTP響應代碼指示API錯誤-React Universal Blog構建展示了其功能。
2.         Uber還依靠Google Maps APITwilio APIBraintree APISendGrid API來為其應用程序提供動力。
3.         Slack有一個API,使您可以將其消息傳遞功能集成到第三方應用程序中。
 
 Webhook介紹
什麼是WebhookWhat is a Webhook?
有時,Webhooks被稱為反向API,但這並非完全正確。它們不會向後運行,但是不需要在您端啟動請求,只要有新數據可用就發送數據。
要設置一個Webhook,您所要做的就是向公司註冊一個URL,以證明您要從中請求數據的服務。該URL將接受數據,並可以激活工作流以將數據轉化為有用的東西。在大多數情況下,您甚至可以指定提供商將向您提供數據的情況。
WebhooksAPI在發出請求的方式上有所不同。例如,無論是否有數據更新響應,API都會發出數據調用。雖然webhooks僅在您連接到的外部系統進行數據更新時才通過HTTP POST接收呼叫。


何時使用WebhookWhen to Use a Webhook?
Webhook通常用於執行較小的請求和任務,但是在某些情況下,Webhook比整個API更合適。
一種常見的情況是您的應用程序或平台需要實時更新,但又不想浪費資源。在這種情況下,webhook將是有益的。
API上使用Webhook的另一種情況是當API非常差或沒有API開頭時。您可以創建解決方法,以為您的應用提供功能所需的數據。
但是,關於Webhook有個警告。由於它們不用於定期請求數據,僅當有新數據可用時才這樣做,因此,如果系統由於某種原因脫機,則有可能永遠無法學習新更新。由於必須接受給定更新可用的總數據量,因此您對總數據流的控制也將更少。
現實生活中的Webhook示例
許多應用程序和工具確實依賴於Webhooks,但是主要是針對較小的數據請求,而不是使用它們來構成其服務的骨幹。仍然有很多有效使用webhooks的例子。
1.         任何人發布新博客帖子或更新其CMS中的內容時,ButterCMS Webhook都會觸發。
2.         Zapier本質上是一個巨大的網絡掛鉤。您將某些應用程序鏈接在一起,只要其中一個事件發生,就會觸發另一個應用程序的動作。
3.         Stripe有一個Webhook,每當訂閱付款失敗時,它將自動向客戶發送電子郵件。



WebhooksAPI運行於不同的圈子
這不是一個更好的情況,因為在任何情況下都沒有一種方法勝過另一種方法。有關您的應用程序的目的和您所請求的數據類型的問題更多。
例如,您可以將API視為發送給朋友的短信,以獲取有關他們所主持活動的更多信息。您問一個問題,他們會發送答复。
借助Webhook,您可以告訴朋友一次在組織另一個活動時給您發短信,只是讓您知道。您提出了初始請求,並且在出現新信息時,它們會不斷向您發送更新。
最後,大多數應用程序最終都會同時使用API​​Webhooks來創建一個可以在正確的時間傳達正確的數據類型的系統。

文章參考:

沒有留言:

張貼留言