Protocols for communicating over web sockets

Question

I'm working on the client-side of a project with a large and complex server-side component. The client will be deployed as an mobile app among other contexts.

For client-server communication, there are two opposing views:

• Use REST
• Use web sockets

Personally, I don't mind which approach is taken so long as the resulting API is well thought out, understandable and extensible.

From experience with using TCP sockets before on a complex C++-based application, I know that roll-your-own syntax/protocols can quickly get inconsistent, confusing and difficult to manage.

Are there any general purpose styles or protocols, like REST or SOAP, for client-server communication using web sockets? Are there any guidelines or best practices on designing your own client-server communication scheme/protocol?

Answer 1

Have you looked at WAMP?

From the above page:

The WebSocket Protocol is already built into modern browsers and provides bidirectional, low-latency message-based communication. However, as such, WebSocket it is quite low-level and only provides raw messaging.

Modern Web applications often have a need for higher level messaging patterns such as Publish & Subscribe and Remote Procedure Calls.

This is where The WebSocket Application Messaging Protocol (WAMP) enters. WAMP adds the higher level messaging patterns of RPC and PubSub to WebSocket - within one protocol.

Technically, WAMP is an officially registered WebSocket subprotocol (runs on top of WebSocket) that uses JSON as message serialization format.

WAMP embraces open Web standards and was designed to be easy to use and simple to implement.

Answer 2

Without any intended slight, Jesse, I'm going to answer my own question after some research.

I didn't come across any equivalents to REST. The current trend appears to be to use JSON to send and receive objects. That seems sensible in a JavaScript-orientated world and allows messages to immediately update data on receipt.

For example:

• https://developer.mozilla.org/en-US/docs/WebSockets/Writing_WebSocket_client_applications
• http://blog.new-bamboo.co.uk/2010/2/10/json-event-based-convention-websockets

I gave a stab at writing my own protocol along these lines. However, the most fully defined protocol along I came across is JSON-RPC. An additional plus about that protocol is that the same messaging system can be used over HTTP and WebSockets, should you be writing in a mixed-sockets and HTTP application.

Another approach I came across was to "port" exiting messaging protocols to WebSockets (regardless of whether they use JSON or not). So, for example, XML-RPC (which JSON-RPC is based on) could be re-implemented fairly simply for use over sockets. Indeed, SOAP also could be re-implemented over sockets.

A nice, small, protocol I came across though one of the above links was STOMP. That could also be ported - and indeed has.

Answer 3

Assuming java, I like Cometd (www.cometd.org) as a mechanism for messaging which sits on top of protocols like http, websocket or even spdy or whatever new protocol comes down the pike. The attraction of something like that is that you code to that api and it seamlessly sorts out what the best underlying protocol is for the given client/server combination. If you are on old IE then it falls back to normal normal http but if it is a new IE then it might choose websockets. If you are on chrome or firefox then you'll get spdy, and when http/2.0 lands which is based on spdy you'll be able to update cometd and get that for free. Also with a more advanced protocol on top of websockets you get things like message recovery in case of things like going through a tunnel and losing connectivity. Works well for a chat application or an app where you want to maintain state through ordered messages, etc. I like the bayeux protocol (which is what cometd implements) for those sorts of features.

So personally, I don't really see REST and websocket as competing or opposing, they are different creatures. REST is a solution born of HTTP style stateless environs and toying with conventions for urls, whereas websocket is a replacement protocol for http. With REST it is unlikely you will ever concern yourself with warming up a TCP connection so you get better throughput but those sorts of things become more common in potentially longer lived connections like websocket or spdy. While http/1.1 with pipelining is an option for that it hasn't lived up to its potential because of lackluster support until mobile browsers really started using it by default rather recently.