Home > Async Http client, Atmosphere, Websocket > Transparently adding WebSockets to your application using SwaggerSocket

Transparently adding WebSockets to your application using SwaggerSocket

Today at Wordnik we announced the immediate availability of SwaggerSocket, a REST over WebSockets protocol that build on of Atmosphere and AsyncHttpClient. In this blog I will give some details about how the protocol works and how we implemented it.

First let’s gives some details about how SwaggerSocket works. SwaggerSocket build on top of the Atmosphere WebSocketProtocol API. The Atmosphere Runtime dispatchs WebSocket events to WebSocketProtocol API, allowing the manipulation of WebSockets events. It is important to note that Atmosphere Runtime takes care of all the WebServer WebSocket details (remember there is no standard on the server side with WebSocket). That why writing a WebSocket application with Atmosphere is portable and can be run on top of Netty, Jetty, GlassFish and Tomcat WebSocket implementation. By default, Atmosphere uses the SimpleHttpProtocol for dispatching WebSocket events to framework or application.

The SimpleHttpProtocol is “simple”: when a WebSocket message is received, it is dispatched as a POST to applications and frameworks. As an example, the Jersey Framework works without any modification inside Atmosphere and transparently work with WebSocket. But you can’t dynamically pass information like form/query params and headers unless you add those inside the WebSocket message itself, by writing your own “sub protocol”. Worse, why waiting for a response to arrive before sending another one? Why not sending an array of requests and get responses as they come, asynchronously? This is where SwaggerSocket can saves our life!

The SwaggerSocket Protocol is exactly that, a Protocol on top of WebSocket. The First version of the Protocol is using JSON to pass information between the client and server. As an example, a WebSocket message looks like:

    "requests" : [
            "uuid" : 0,
            "method" : "POST",
            "path" : "/foo",
            "headers" : [
                    "name" : "Content-Type",
                    "value" : "application/json"
            "queryStrings" : [
                    "name" : "foo2",
                    "value" : "bar2"
            "messageBody" : "SwaggerSocket Protocol is cool"

A Response looks like

    "responses" : [
            "uuid" : 0,
            "status" : "status",
            "path" : "/foo",
            "headers" : [
                    "name" : "name",
                    "value" : "value"
            "messageBody" : "You are right! SwaggerSocket is coool!"

It is important to note that any existing applications will WORKS AS IT IS, without any modifications server side. That means your Wicket/GWT/Vaadin/Resis/Hazelcast/Jersey/Spring/Guice/RichFaces/etc. can take advantage of the protocol right now. As an example, a simple Jersey resource:

class HelloWorld {

  def get(): String = {
    "Swagger Socket Hello World"

will run unmodified. For the client, you have choice:

  1. Open a WebSocket and use the swaggersocket-protocol library to create requests and responses
  2. Use the swaggersocket.js library
  3. Use the SwaggerSocket Scala Library, which build on top of AHC (AsyncHttpClient) WebSocket

I strongly recommends the use of 2 and 3, but would like to see contribution for 1 :-). Our goal is to integrate SwaggerSocket with Swagger and ships other client language as well.

With Javascript, all you need to do is:

        $(document).ready(function() {
  new jQuery.swaggersocket.SwaggerSocket()
     .open(document.location.toString() + "ss",
          function(swaggerSocket, r) {
              if (r.getStatus() == 200) {
              var ss = new jQuery.swaggersocket.SwaggerSocketListener();
              ss.onResponse = function(r) {
               // Write the response

              var request = new jQuery.swaggersocket.Request()


All you need to do is to create a SwaggerSocket, invoke the open method and pass a function that will be invoked when the initial handshake as succeeded. Then you can call swaggerSocket.sendto send a single or an array of requests. You can do the same using the SwaggerSocket Scala Library:

  val ss = SwaggerSocket().open("")
  ss.send(new Request.Builder()
   .build(), new SwaggerSocketListener() {
  	override def message(r: Request, s: Response) {
        // print the response using response.getData()

The fun just begin! We will soon add support for other transport like Server Side Events, Long-Polling, HTTP Streaming and JSONP so you can deploy your SwaggerSocket application in your current production infrastructure which most probably isn’t supporting WebSocket yet. But you don’t have to wait for WebSocket, Atmosphere always use the best available one and the framework makes sure to switch to WebSockets when available.

I strongly encourage you to take a look at our demos, specially the Twitter one that bring real time search to Twitter, as fast as what Google Search recently started to support.

For any questions or to download SwaggerSocket, go to our main site, use our Google Group forumfollow the team or myself and tweet your questions there!

  1. uatecuk
    April 27, 2012 at 8:25 am

    What a stupid idea. Http is implemented on TOP of sockets.

    Why implement sockets on top of HTTP on top of sockets. It makes no sense.

    If you want to do an application that uses sockets. Learn to write an application, not a website.

    • April 27, 2012 at 5:09 pm

      Nice catch. I’ve just updated the table. WebLogic 12.x supports Servlet 3.0 so long-polling, streaming and JSONP will works. Thanks!

  2. April 27, 2012 at 5:46 pm

    This is excellent! I feel it is the next logical progression in the evolution of Web Apps:

    Plain HTTP > Ajax > Comet > WebSockets > SwaggerSockets

    This should allow for highly scaleable Web Apps that behave more like traditional desktop apps.

  3. buffalo
    March 31, 2013 at 1:17 am

    I am finding that the swaggersocket examples do not run in Jetty 9. Have you any insight on what might be the issue?

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: