Jetty WebSocket api與標准JSR 356 API相比

Question

碼頭9支持兩種它自己的Jetty的WebSocket API，以及標准的JSR 356 API，為我承擔其歷史原因（Jetty的API 之前的最后JSR 356 ）。

我查看了兩個API的基本文檔，以及一些示例。 這兩個API看起來相當完整且非常相似。 但是，我需要為我正在編寫的新項目選擇一個而不是另一個，並且我希望避免使用可能在將來被棄用的API，或者可能會變得功能不足。

那么兩者之間是否有任何重要的區別，除了一個標准化的明顯事實？

Answer 1

這兩個Jetty的執行者:)

Jetty WebSocket API首先出現，而JSR-356 API則建立在它之上。

JSR-356 API執行Jetty WebSocket API沒有的一些功能，例如

• 解碼器用於自動Bin / Text to Object轉換
• 編碼器用於自動對象到文本/文本轉換
• 路徑參數處理（也稱為方法參數映射的自動URI模板）

但是，Jetty WebSocket API可以執行JSR-356 API無法做到的事情。

• WebSocketCreator邏輯用於任意創建WebSocket端點，可以訪問HttpServletRequest
• 更好地控制超時
• 更精細的緩沖區/內存配置
• 您可以管理WebSocket Extensions
• 支持端點的基於Reg-ex的路徑映射
• 訪問原始Frame事件
• WebSocket客戶端支持HTTP代理（JSR-356獨立客戶端沒有代理的配置選項）
• WebSocket客戶端支持更好的連接邏輯和超時
• WebSocket客戶端支持SSL / TLS（JSR-356獨立客戶端沒有SSL / TLS的配置選項）
• 從活動WebSocket Session對象訪問兩個InetAddress端點信息
• 從活動WebSocket會話對象訪問UpgradeRequest
• 更好地支持無狀態端點
• 讀取事件支持掛起/恢復邏輯，以允許應用程序進行一些基本的tcp背壓/流量控制
• 基於過濾器或基於Servlet的配置（JSR-356方法要求在所有其他servlet和過濾器處理之前進行升級）

希望這有幫助，如果你想了解更多細節，請使用jetty-users郵件列表 ，因為這類問題真的不適合stackoverflow。