Public WebSocket Endpoints – Sandbox by Kaazing

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.

Testing 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: wss://demos.kaazing.com/echo

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.

To see the power of pub-sub messaging using AMQP 0-9-1, take a look at the AMQP Messaging Demo for JavaScript.

The endpoint for AMQP 0-9-1 over WebSocket is: wss://demos.kaazing.com/amqp

Secure vs. non-secure WebSocket connection

The above WebSocket endpoints use WebSocket over TLS (wss), but the sandbox also supports non-encrypted connections: ws://demos.kaazing.com/amqp.

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.

And last, but not least, if you want to see a couple of really cool apps built on top of this technology, take a look at the multi-touch Remote Mouse, and the WebSocket JavaScript Racer demos. Both of these demos use AMQP 0-9-1 for pub-sub messaging over WebSocket.