Jetty WebSocket api vs the standard JSR 356 API

荒凉一梦 提交于 2019-11-30 09:04:44

Implementor of both on Jetty here :)

The Jetty WebSocket API came first, and the JSR-356 API is built on top of it.

The JSR-356 API does a few things that the Jetty WebSocket API does not, such as

  • Decoder's for automatic Bin/Text to Object conversion
  • Encoder's for automatic Object to Bin/Text conversion
  • Path Param handling (aka automatic URI Template to method param mapping)

However, the Jetty WebSocket API can do things the JSR-356 API cannot.

  • WebSocketCreator logic for arbitrary creation of the WebSocket endpoint, with access to the HttpServletRequest
  • Better control of timeouts
  • Finer buffer / memory configurations
  • You can manage WebSocket Extensions
  • Supports Reg-ex based Path mappings for endpoints
  • Access to raw Frame events
  • WebSocket client supports HTTP proxies (JSR-356 standalone client has no configuration options for proxies)
  • WebSocket client supports better connect logic with timeouts
  • WebSocket client supports SSL/TLS (JSR-356 standalone client has no configuration options for SSL/TLS)
  • Access to the both InetAddress endpoint information from the active WebSocket Session object
  • Access to UpgradeRequest from active WebSocket Session object
  • Better support for stateless endpoints
  • Read events support suspend/resume logic to allow application some basic tcp backpressure / flow control
  • Filter based or Servlet based configuration (the JSR-356 approach requires upgrade to occur before all other servlet and filter processing)

Hope this helps, if you want more details, please use the jetty-users mailing list, as this sort of question is really inappropriate for stackoverflow.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!