使用阻塞REST請求來實現發佈/訂閱

Question

我最近被要求調查與電話系統供應商進行整合的可行性，他們希望使用RESTful進行電話事件（例如，線路振鈴，分機應答，呼叫清除）網絡服務。

我指出REST是一個請求/響應協議，他們在做發佈/訂閱。他們建議的解決方案是製作一個HTTP REST請求，該請求會阻止並最終在事件可用或超時時響應。

無論哪種方式，另一個請求將被用來獲得下一個事件等無限期。

這個想法讓我感到畏縮，但我確信iPhone「推送」電子郵件是這樣操作的。

這是合理使用REST嗎？

Answer 1

我要說的是，它不與REST架構風格飛得好（主要是因爲REST它約束到無狀態的客戶端服務器交互）。然而，網絡上有豐富的解決方案，可以長時間輪詢，儘管沒有網絡精神，但它或多或少地起作用。

首先，在體系結構的注意事項：實現REST內的pub/sub僅僅意味着出版商增加了項目，然後是提供給用戶的列表。訂戶對該列表進行了輪詢。有一些方法可以確保一次只能一次，同時保持消息訂單和（一種形式）的保證傳送，雖然是異步的。它的規模非常好，而且非常有彈性。

我的第一條建議是使它可選，這樣不能執行長輪詢（或不願意）的客戶可以這樣做。我甚至會說，如果一個普通的客戶端（如谷歌）的默認值是而不是來執行長輪詢，並且服務器通過客戶端和客戶端之間的特殊共享理解來啓動長輪詢服務器。這種共同理解可以是自定義媒體類型或自定義鏈接關係，甚至可以是通用客戶端不知道的自定義HTTP頭。支持長時間輪詢的客戶端將編碼爲發現長輪詢的功能，並根據需要調用該功能，如果長輪詢失敗（例如中介以某種方式阻止），則回到常規輪詢。

，而不是試圖做到這一點在HTTP之上而且，我會建議使用非HTTP套接字關於這個問題，不違反HTTP的意圖和有效地使用HTTP作爲傳輸協議。參見cometd。

我的另一條建議是問你的客戶應該如何「實時」。如果幾秒鐘的延遲時間是可以接受的，那麼由於使用常規輪詢解決此問題的緩存性質，即使對於大量客戶端，您也可以進行常規輪詢。