我正在尋求將web hooks作爲應用程序REST API的一部分來實現。爲批量操作實現Web掛鉤
最初我們希望實現API消費者的機制來註冊實體更新的事件。因此,如果實體發生變化,我們會調用所有在該實體上註冊更改事件的webhook(並且作爲註冊過程的一部分,API消費者可以包含額外的過濾標準,以確保他們只接收對他們感興趣的實體子集的回調在)。
現在 - 這對用戶啓動的更改非常有效,它將緩慢地流入,但我擔心在發生大量更改時如何最好地處理此問題 - 例如,作爲在羣集中執行的批量操作的一部分UI或API消費者發生的大量更改。
到目前爲止,我還認爲:
- 只是做了回調爲每個實體,使用某種異步池 - 問題,我在這裏看到的是規模和可能造成的危害這些應用程序訂閱網絡掛鉤。
- 排隊每個webhook註冊更改記錄,比如說10秒的窗口,然後推送一個webhook通知到訂閱與受影響的實體列表 - 我在這裏看到的問題是,我們在行動之間引入不必要的延遲和webhook,當事件只是在流淌時 - 這也引入了一些開銷和複雜性,特別是如果在web場場景中實現這一點。
- 實際上將批量操作暴露爲網頁掛鉤 - 所以如果執行批量刪除,消費者會訂閱此操作。因此,爲單個實體更改設置掛鉤將不會收到批量更新/刪除等任何實體更改事件 - 它們必須通過批量操作Web掛鉤來處理此事件。
由於一些額外的細節 - 在這個應用程序中的批量操作可能會包含10到10萬個實體之間的任何地方。
是否有人對批量操作實施了Web鉤子,這些批量操作可以闡明他們如何決定實現這一點?
我也有所有這些問題,再加上在調用webhook時不阻止主HTTP處理。你最終採用了什麼解決方案?你對2017年有何建議? (最好用Python/Lambda) –