12

Jetty 9 支持它自己的 Jetty Websocket API 以及标准的 JSR 356 API，我认为这是历史原因（Jetty 的 API在最终的 JSR 356之前）。

我查看了这两个 API 的基本文档以及一些示例。这两个 API 看起来都相当完整且相当相似。但是，我需要为我正在编写的一个新项目选择一个，并且我想避免使用将来可能会被弃用或功能不那么丰富的 API。

那么，除了一个是标准化的这一明显事实之外，两者之间是否有任何重要区别？

4

1 回答 1

19

Jetty 上两者的实现者：)

Jetty WebSocket API 最先出现，JSR-356 API 建立在它之上。

JSR-356 API 做了一些 Jetty WebSocket API 没有做的事情，比如

  • 用于自动 Bin/Text 到 Object 转换的解码器
  • 用于自动对象到 Bin/Text 转换的编码器
  • 路径参数处理（又名自动 URI 模板到方法参数映射）

但是，Jetty WebSocket API 可以做 JSR-356 API 不能做的事情。

  • 用于任意创建 WebSocket 端点的 WebSocketCreator 逻辑，可访问 HttpServletRequest
  • 更好地控制超时
  • 更精细的缓冲区/内存配置
  • 您可以管理 WebSocket 扩展
  • 支持基于 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 来说确实不合适。

于 2014-09-10T21:32:54.897 回答