6

A bit of background first, I'm working on an application that manages a piece of physical equipment with motors, stuff like that. When I started on the project, there was an existing application, built with Labview and that was in a poor state. The part of the code that manages the hardware, the "drivers" were in a better shape. The goal was to write a new app, in .Net, but reusing as much as possible the existing drivers.

The architecture that was decided was to separate strongly the hardware side, written in Labview, and the management/data treatment side written in C# through the use of a REST web service, since Labview has a relatively good support of them. The Labview hardware part has the role of the server, and the .Net side connects through it, asks for status of the hardware and sends command to move the hardware and so on.

In so far, it works pretty well, the only annoying part is the amount of polling that is needed from the client side. We have some "long commands", for which we send a command that asks the hardware to do a long operation, but we want to have some updates on how it goes. For this, we send the PUT to initiate the action and then, every 500 ms (or slower depending on the action), we send a GET to have the current status of the action, until the action is done (usually defined by a flag).

When I started with the project, a few months ago, I had seen this issue and did some research to see if there was a solution to this problem, like a way to use SignalR for Labview, and didn't find anything. But now, we have found an implementation of a WebSocket server in Labview. I'm now wondering if and how this could be implemented in (or as a replacement of) our solution.

One of the solution I was envisioning was to keep the REST service for most, but create on the fly a WebSocket endpoint for those few long-lasting commands that need updating. For example, send a PUT command to do an action, for which the server would start the action, return the 200 OK and add the address of a WebSocket endpoint where the client could go to get status. As soon as the client connects to the WebSocket, the server would send updates through this. When the action is done, connection is closed, and WebSocket endpoint is closed on the server side.

I've searched a bit to see if someone were doing that kind of "mixed" service, but cannot find anything, so I'm wondering if it's really a good idea. Even though I'm not a huge fan of the amount of polling that happens now, I also really like the REST API that we have created and feel like it would be a bit of a loss to scrap it and go the WebSocket way completely. I think WebSocket is still not as universal as REST (even in .Net 4.5, the ClientWebSocket class is useable only in Windows 8, even though alternatives exists). Using WebSocket also means defining our own communication protocol (how to define commands, etc.) which can be difficult.

In a way, mixing doesn't seem completely "right" either, because I'm not going to use completely the "full-duplex" advantage of WebSocket, mostly using them for communicating back information from the server to the client in a sort of "push" way, rarely sending commands from the client to the server through the web socket.

  • Your initial problem was polling. Isn't it a option to use websocket only for notifications from server to clients? The clients can use then the existing api to pull the changes from server. It would be the cheapest and most stable solition in your situation. – Waldemar Apr 14 '15 at 7:24
  • You mean to let the client know that something has changed, and not actually sending the data through the websocket? Yes, that would be an interesting idea. How would the client register to the websocket then? – Gimly Apr 14 '15 at 8:09
  • The clients initiate a wobsocket connection at the beginning of the session by sending an upgrade (from http to websocket) request. – Waldemar Apr 15 '15 at 11:53
2

It's all about discovery: the ability of your API to be understandable and usable by the next developer encountering it. If the WebSocket methods are easily discoverable, and it is clear that they should be used in conjunction with the ordinary REST methods, then your design is probably sound.

In practice, for this discovery to occur, I think your WebSocket methods need to be defined in close proximity with your ordinary REST methods, along with some clarifying comments suggesting their proper use and coordination.

If the WebSocket methods are meant to be used independently of the REST interface, then you can put them in their own API.

  • Discoverability and ease of use is one of the things I like with the current REST solution we have, which I think will be more difficult to do with a 100% WebSocket API. My goal of incorporating the WebSocket endpoint into REST response was to make clear how they could be used. – Gimly Mar 13 '15 at 23:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.