I have started to develop a Rails application, and decided to use websockets as a way to push notifications to the client - and am using basic HTTP requests to get and manipulate data on the server.
Now, websockets allows you to send messages from the client to the server, a feature I currently am not sure when to use - I mean I can always do post requests.
This feels somewhat odd to me - so I guess I am doing something wrong - why should I send HTTP requests when there is already a connection between the client and the server? it could just send a message through the websocket, and request the data to be pushed back to it.
I guess the websocket protocol isn't meant to fully replace http - and servers should support both - so I am wondering, what was the intended usage? - when should I send messages from the client through the websocket and when should I use POST for example?
Related
When speaking from a conceptual point of view, is it standard practice to mix WebSockets and HTTP requests when making a chat application (or any application that requires real-time communication between devices)?
Imagine a scenario with a client and a server in a chat app. What would be the best approach for connecting and sending data between the client and the server? Would it be using sockets for both sending and receiving or HTTP requests for sending (so the client would get a response and then know if the message was received), and then using WebSocket for only receiving new messages?
No this is not standard practice.
If you need real-time communication between client and server you normally just use a websocket connection and keep that one open. The client can send messages to the server and receive messages through the same connection.
Using HTTP requests for sending messages to the server and receiving new messages via websocket seems odd and just adds unnecessary complexity.
Now if your server has some endpoints to subscribe for real-time data e.g. a chat room and endpoints for getting information you don't necessary want to subscribe to e.g. information about a certain user, than you can use the appropriate protocol for each endpoint
I have a question regarding http requests and responses.
I know that I can send a request to a server from my device (I can build and send a GET request to http://google.com for example). But what if I am Google and I want to send a request from the server to the user's device? How do I do that?
I understand that when the server receives a request, it can answer it, but in this case I want the server to send the request to the user's device. Just like WhatsApp does when you receive a new message.
Thanks for the help!
There are several options for sending information from the server to a client:
Push notifications - depends on the platform you are using
Constructing a Websocket connection that allows bi-directional communication
I'm sure there are more options but those are the two that come up to my mind right away.
It really depends on your application use case. For example, a chat application would like to have a socket open between it and the server so it can update frequently on new messages, etc. On the other had some simple Calendar applications might want to use push notifications to send reminders on certain dates and times.
I had a data received by websocket client Now i want it to send to http server . Is there any method to store the data outside message event ?
Or
Can i convert websocket client back to http client ??
No, a WebSocket connection can't be "downgraded" back to HTTP.
But yes, moving the information out of the WebSocket event and starting a new HTTP request is quite trivial... though implementation details would (obviously) depend on language, environment etc'. i.e., a browser client implementation will be very different from a C client.
Note that the server can't initiate an HTTP request, but the server can ask the client to do so.
When an http connection is upgraded to a websocket connection can my javascript code still use http ajax GET requests for example? That is, I can do both normal http requests and websocket messages or does "upgraded to websocket" mean the http capabilities are gone?
If your server supports both normal web requests and WebSocket upgrades (some servers are either one or the other), then you can continue to make AJAX requests even while you have a WebSocket connection. AJAX (XMLHttpRequest) requests are just regular HTTP/HTTPS requests that are initiated by Javascript rather than by the browser when the page loads. Having an active WebSocket connection will not interfere with other HTTP/HTTPS (or AJAX) connections. Unless of course the server has a bug.
At the moment I have an existing application which basically consists of a desktop GUI and a TCP server. The client connects to the server, and the server notifies the client if something interesting happens.
Now I'm supposed to replace the desktop GUI by a web GUI, and I'm wondering if I have to rewrite the server to send http packets instead of tcp packets or if I can somehow use some sort of proxy to grab the tcp packets and forward them to the web client?
Do I need some sort of comet server?
If you can make your client ask something like "Whats new pal?" to your server from time to time you can start implementing HTTP server emulator over TCP - its fun and easy process. And you could have any web based GUI.
You can just add to your TCP responds Http headers - itll probably do=)
So I mean HTTP is just a TCP with some headers like shown in here.
You should probably install fiddler and monitor some http requests/ responses you normally do on the web and you'll get how to turn your TCP server into http emulator=)
If you want keep sockets based approche use flash (there is some socket api) or silverlight (there is socket API and you can go for NetTcpBinding or Duplexbinding something like that - it would provide you with ability to receive messages from server when server wants you to receive them (server pushes messages))
So probably you should tall us which back end you plan to use so we could recomend to you something more usefull.