webhooks是乙個api概念，是微服務api的使用正規化之一，也被成為反向api，即：前端不主動傳送請求，完全由後端推送。 舉個常用例子，比如你的好友發了一條朋友圈，後端將這條訊息推送給所有其他好友的客戶端，就是 webhooks 的典型場景。
簡單來說，webhook就是乙個接收http post（或get，put，delete）的url。乙個實現了webhook的api提供商就是在當事件發生的時候會向這個配置好的url傳送一條資訊。與請求-響應式不同，使用webhooks，你可以實時接受到變化。
這又是一種對客戶機-伺服器模式的逆轉，在傳統方法中，客戶端從伺服器請求資料，然後伺服器提供給客戶端資料（客戶端是在拉資料）。在webhook正規化下，伺服器更新所需提供的資源，然後自動將其作為更新傳送到客戶端（伺服器是在推資料），客戶端不是請求者，而是被動接收方。這種控制關係的反轉可以用來促進許多原本需要在遠端伺服器上進行更複雜的請求和不斷的輪詢的通訊請求。通過簡單地接收資源而不是直接傳送請求，我們可以更新遠端**庫，輕鬆地分配資源，甚至將其整合到現有系統中來根據api的需要來更新端點和相關資料，唯一的缺點是初始建立困難。
更新客戶端，在資源新建或者更新時提供更新的、指定的資料。
對於第三方平台驗權、登陸等 沒有前端介面做中轉的場景，或者強安全要求的支付場景等，適合用 webhooks 做資料主動推送。說白了就是在前端無從參與，或者因為前端安全問題不適合參與時，就是 webhooks 的場景。很顯然 webhooks 也不是 http 的替代品，不過的確是一種新的前後端互動方式。
如果客戶端要長期監聽某個任務的狀態，按照正常的api呼叫的方式去做，那麼必須不停得輪訓伺服器來獲取當前狀態；使用webhook則無需輪訓，通過api 可以確定是否發生了更改，如果更改了只需要等待伺服器推送資訊過來，然後客戶端更新就可以。git webhook其實也是這方面的應用。
2、webhook會發出大量的請求，這樣會造成你的應用阻塞。確保你的應用能處理這些請求。
CMSIS RTOS功能概述
以下列表簡要概述了所有cmsis rtos功能。標有 的函式是可選的。特定的cmsis rtos實現可能無法提供所有功能，但osfeature x定義明確指出了這一點。注意rtx實現不支援的功能標有 執行緒管理 通用等待功能 定時器管理 訊號事件 互斥訊號燈 記憶池訊息佇列 郵件佇列 rtx特定功能...
Windows Virtual PC 功能概述
輕鬆的安裝配置 windows xp mode 在完成了 windows virtual pc 和 windows xp mode 的安裝後，我們通過 windows virtual pc 提供的簡單嚮導，只需要單擊幾次便能輕鬆地完成 windows xp mode 的安裝和配置。而不必像傳統安裝方...
webhook 掛鉤自動部署
假設我們現在有乙個需求，就是將專案打包上傳到gitlab或者github後，程式能自動部署，不用手動地去伺服器中進行專案更新並執行，如何做到？這裡我們可以使用gitlab與github的掛鉤，掛鉤的原理就是，每當我們提交請求到gitlab與github伺服器時，這時他倆會根據我們配置的訪問地扯進行訪...