We are receiving as of lately many questions about WebSockets and Telco APIs.
Solaiemes started implementing WebSockets interfaces accross all our infrastructure in 2013, with working prototypes available since the summer. We are sharing now that experience to help the operators looking at this topic. Most likely WebSocket support will be included in the RCS OMA API spec soon and Solaiemes wants, among other API flavours, offer the standardized for the customers requiring it.
In our experience, WebSockets is first and foremost useful for Telco API developers as an additional notification channel. Existing notifications can be reused without any change, because WebSockets provide a native framing mechanism and it is agnostic about the format. Existing notification processing code can be reused.
This approach makes even more sense as in many cases WebSockets won't be available (for example, behind some corporate firewalls), so it is advisable to keep existing channels (native messaging, long polling, etc.).
From the developer point of view, it is just needed to plug (or activate) javascript plugins that automatically manage the transport used (long polling, web sockets, etc.), such as Atmosphere, Socket.io, etc.
On the infrastructure side, a new notification transport is added, but existing APIs can be kept, as REST or whatever format, because there is no need to move the whole API package to WebSockets.
Solaiemes has also API invocation over WebSockets implemented. It is very easy to transform an HTTP-based invocation model (REST or pseudo-REST) to WebSockets, but in our experience the benefits are not so evident, specially as WebSockets are not as ubiquitous as other HTTP mechanisms and scalability solutions do not play well with WebSockets in some scenarios.
WebSockets may be used where its use has a positive impact but not in the cases that its applicability is a mere "reinventing the wheel" without no straightforward advantage.
Posts
