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?
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:
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.