2012-09-19 28 views
3

我正在尋求將web hooks作爲應用程序REST API的一部分來實現。爲批量操作實現Web掛鉤

最初我們希望實現API消費者的機制來註冊實體更新的事件。因此,如果實體發生變化,我們會調用所有在該實體上註冊更改事件的webhook(並且作爲註冊過程的一部分,API消費者可以包含額外的過濾標準,以確保他們只接收對他們感興趣的實體子集的回調在)。

現在 - 這對用戶啓動的更改非常有效,它將緩慢地流入,但我擔心在發生大量更改時如何最好地處理此問題 - 例如,作爲在羣集中執行的批量操作的一部分UI或API消費者發生的大量更改。

到目前爲止,我還認爲:

  • 只是做了回調爲每個實體,使用某種異步池 - 問題,我在這裏看到的是規模和可能造成的危害這些應用程序訂閱網絡掛鉤。
  • 排隊每個webhook註冊更改記錄,比如說10秒的窗口,然後推送一個webhook通知到訂閱與受影響的實體列表 - 我在這裏看到的問題是,我們在行動之間引入不必要的延遲和webhook,當事件只是在流淌時 - 這也引入了一些開銷和複雜性,特別是如果在web場場景中實現這一點。
  • 實際上將批量操作暴露爲網頁掛鉤 - 所以如果執行批量刪除,消費者會訂閱此操作。因此,爲單個實體更改設置掛鉤將不會收到批量更新/刪除等任何實體更改事件 - 它們必須通過批量操作Web掛鉤來處理此事件。

由於一些額外的細節 - 在這個應用程序中的批量操作可能會包含10到10萬個實體之間的任何地方。

是否有人對批量操作實施了Web鉤子,這些批量操作可以闡明他們如何決定實現這一點?

+0

我也有所有這些問題,再加上在調用webhook時不阻止主HTTP處理。你最終採用了什麼解決方案?你對2017年有何建議? (最好用Python/Lambda) –

回答

1

我們最近實現了Web鉤子作爲我們其餘API的一部分,我們主要關心的還是批量操作。在我們的情況下,它是批量導入,用戶可以通過我們的Web應用程序將記錄導入到excel或csv文件中。

我們的導入過程是以這樣一種方式設計的,即整個過程在一個事務中運行。所以如果失敗了,我們只需回滾一下,什麼都不做,如果成功完成,我們會向擁有一個龐大身份的訂閱客戶端發佈一個Web鉤子通知,並提供關於受影響實體的信息。

現在我不確定在您的應用程序中如何執行批量操作。如果它在一個交易中,那麼你沒有問題。其他方面,我建議保持單獨和批量操作Web掛鉤分開。我想這是使用webhooks的一個缺點,你可以通過背靠背POST請求來降低你的訂閱者。