So, you are building a WebSocket app? Or simply want to learn more? Probably the easiest way to get started is by taking a look at publicly hosted WebSocket end-points.
A few years ago we at Kaazing fired up the very first public WebSocket service, the Echo demo on websocket.org. It has been extremely popular and is being used by a vast number of Web developers, enterprise architects, even various government organizations.
We’re excited to share the news that the Echo demo got company in the form of the Kaazing WebSocket sandbox, taking the idea to the next level. The WebSocket sandbox supports two protocols at the moment, pure WebSocket, and AMQP 0-9-1 over WebSocket.
To test the sandbox, all you need is a WebSocket client. One option is to head over to websocket.org, and use the sandbox WebSocket URL as the end-point. In addition, you should check out the new and improved Echo client on kaazing.com that allows you to test blob, array buffer, and byte buffer messages as well, in addition to plain text.
The sandbox endpoint for WebSocket echo is:
Testing AMQP 0-9-1
You may have heard that Kaazing supports several application protocols and APIs layered on top of WebSocket, including AMQP, XMPP, JMS, or even your own custom protocol.
The endpoint for AMQP 0-9-1 over WebSocket is:
Secure vs. non-secure WebSocket connection
The above WebSocket endpoints use WebSocket over TLS (
wss), but the sandbox also supports non-encrypted connections:
Note: Just like
http has a secure counterpart,
https, you can tunnel WebSocket through TLS as well. When doing so, instead of
ws you use the
wss (WebSocket Secure) protocol scheme.
Pro Tip: It is highly recommended that you use
wss, instead of
ws in your production deployments. Not only is it beneficial because your communication is encrypted, but also, because
wss has a way higher success rate penetrating network intermediaries, such as firewalls, proxies, and routers. To learn more about WebSocket security, check out our HTML5 WebSocket Security is Strong blog post.