Beginning to understand web sockets and http requests (and STOMP)

Question

I have recently joined a new project where I am being tasked with implementing streaming data using web sockets. The idea is a bunch of information is being exposed currently through HTTP requests (in a RESTful manner) that they want exposed through web sockets.

I have done a bunch of research in the past 48 hours about web sockets and STOMP and wanted to get some clarification on a few points:

1. So for a client and a server to connect via a web socket rather than through an HTTP request/response, they first need to agree to set up a web socket connection between them. Is this done through HTTP GET with a unique header passed that says they are to use a web socket connection instead?

2. Theoretically, say that there is a whole bunch of different data being exposed through some API to the browser. Imagine there is a whole bunch of different HTTP requests that can be made GET'S, POST'S, DELETE whatever. So to have certain pieces of all this information be streamed via a web socket, is it simply to change the current GET request for each resource to check to see if that special websocket header is there and then do something? Or is there something else that has to be done to expose certain pieces of data through web sockets. I just may of misunderstood the relationship of HTTP and sockets if you initialize a socket from a HTTP request.

I think these are my two main questions and I am sure the answers to these will point me in the right direction to continue learning more about the topic. I am trying to find any good sample code examples but I am trying to understand this well enough to implement within the week.

Answer 1

So for a client and a server to connect via a web socket rather than through an HTTP request/response, they first need to agree to set up a web socket connection between them. Is this done through HTTP GET with a unique header passed that says they are to use a web socket connection instead?

Yes, more or less. The headers are:

Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Key: <random string, base64 encoded>
Sec-WebSocket-Version: <version>

Typically version is 13 these days, although I believe 8 is also still in use.

If the server agrees to the websocket, it will return HTTP code 101 with the following headers:

Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: <base64 encoded hash based on Sec-WebSocket-Key>

Theoretically, say that there is a whole bunch of different data being exposed through some API to the browser. Imagine there is a whole bunch of different HTTP requests that can be made GET'S, POST'S, DELETE whatever. So to have certain pieces of all this information be streamed via a web socket, is it simply to change the current GET request for each resource to check to see if that special websocket header is there and then do something? Or is there something else that has to be done to expose certain pieces of data through web sockets. I just may of misunderstood the relationship of HTTP and sockets if you initialize a socket from a HTTP request.

It sounds like you understand this, but I will point out that you can only start a WebSocket with a GET.

From what you've described, it isn't clear that WebSockets are actually what you want. WebSockets are used for two-way communication between the server and client. If you just want to be able to stream from the server to the client, you'll have a much easier time with Server-Sent Events.

Answer 2

It took me more than 48 hours to really get my head around this. It's a big change from AJAX.

You may be thinking at too low of a level. If you are broadcasting messages to multiple browsers, there are multiple message queue systems that can talk over websockets (many or all of them using STOMP).

If, however, you need to send private data only, you may want to stop at the STOMP level (or lower). The technology isn't really mature at this point, because most of the solutions involve the fore-mentioned message queues. STOMP theoretically should allow you to have multiple endpoints on each side (browser and server) to get messages (serialized in JSON or XML between JavaScript and C#). If you don't like that technology, it is fairly easy to use WebSockets itself to pass messages back and forth. In that case, you have one receiver on each side, and you pass a simple structure like a string that names the message followed by a comma, then the message itself serialized in whichever technology works for you (I prefer JSON on the browser side, but XML could work).

Good luck, and update your question or comment on your accepted answer with anything you learned not in the answer so others will be able to learn from it.

UPDATE: Someone with more information on .NET's implementation of WebSockets please answer with some details that I don't know and don't have the time to investigate. My answer isn't complete, I just don't have the time to answer correctly before the bounty expires.