15

Background

We are writing a Messenger-like app. We have setup Websockets to Inbox and Chat.

Question

My question is simple. What are the advantages and disadvantages when sending data from Client to Server using REST instead of Websockets? (I am not interested in updates now.)

We know that REST has higher overhead in terms of message sizes and that WS is duplex (thus open all time). What about the other things we didn't keep in mind?

Amio.io
  • 20,677
  • 15
  • 82
  • 117
  • Related: [websocket vs rest API for real time data?](https://stackoverflow.com/questions/28613399/websocket-vs-rest-api-for-real-time-data/28618369#28618369) and [Ajax vs. socket.io](https://stackoverflow.com/questions/30319618/ajax-vs-socket-io/30334848#30334848) – jfriend00 Aug 02 '17 at 14:04
  • @jfriend00 Thx for trying to help but I am interested in communication **Client → Server**, not about real-time updates Server → Communication. – Amio.io Aug 02 '17 at 14:34
  • Possible duplicate of [What are the pitfalls of using Websockets in place of RESTful HTTP?](https://stackoverflow.com/questions/29925955/what-are-the-pitfalls-of-using-websockets-in-place-of-restful-http) – Alexandru Marculescu Aug 03 '17 at 07:16
  • Possible duplicate of [websocket vs rest API for real time data?](https://stackoverflow.com/questions/28613399/websocket-vs-rest-api-for-real-time-data) – David Zemens Aug 06 '19 at 00:19

1 Answers1

49

Here's a summary of the tradeoffs I'm aware of.

Reasons to use webSocket:

  1. You need/want server-push of data.
  2. You are sending lots of small pieces of data from client to server and doing it very regularly. Using webSocket has significantly less overhead per transmission.

Reasons to use REST:

  1. You want to use server-side frameworks or modules that are built for REST, not for webSocket (such as auth, rate limiting, security, streaming, etc...).
  2. You aren't sending data very often from client to server and thus the server-side burden of keeping a webSocket connection open all the time may lessen your server scalability.
  3. You want your client to run in places where a long-connected webSocket during inactive periods of time may not be practical (perhaps mobile).
  4. You want your client to run in old browsers that don't support webSocket.
  5. You want the browser to enforce same-origin restrictions (those are enforced for REST Ajax calls, but not for webSocket connections).
  6. You don't want to have to write code that detects when the webSocket connection has died and then auto-reconnects and handles back-offs and handles mobile issues with battery usage issues, etc...
  7. You need to run in situations where there are proxies or other network infrastructure that may not support long running webSocket connections.
  8. If you want request/response built in. REST is request/response. WebSocket is not - it's message based. Responses from a webSocket are done by sending a messge back. That message back is not, by itself, a response to any specific request, it's just data being sent back. If you want request/response with webSocket, then you have to build some infrastructure yourself where you tag an id into a request and the response for that particular request contains that specific id. Otherwise, if there are every multiple requests in flight at the same time, then you don't know which response belongs with which request because all the data is being sent over the same connection and you would have no way of matching response with request.
  9. If you want other clients to be able to carry out this operation via an Ajax call.

So, if you already have a webSocket implementation, don't have any problem with it that are lessened with REST and aren't interested in any of the reasons that REST might be better, then stick with your webSocket implementation.

Related references:

websocket vs rest API for real time data?

Ajax vs Socket.io

Adding comments per your request:

It sounds like you're expecting someone to tell you the "right" way to do it. There are reasons to pick one way over the other. If none of those reason compel you one way vs. the other, then it's just an architectural choice and you must take in the whole context of what you are doing and decide which architectural choice makes more sense to you. If you already have the reliably established webSocket connection and none of the advantages of REST apply to your situation then you can optimize for "efficiency" and send your data to the server over the webSocket connection.

On the other hand, if you wanted there to be a simple API on your server that could be reached with an Ajax call from other clients, then you'd want your server to support this operation via REST so it would simplest for these other clients to carry out this one operation. So, it all depends upon which direction your requirements drive you and, if there is no particular driving reason to go one way or the other, you just make an architectural choice yourself.

jfriend00
  • 683,504
  • 96
  • 985
  • 979
  • Hey @jfriend00, we have websockets already. **My question is about sending data from Client to Server**. Shall we use Websocket or REST and why? But thank you for trying. – Amio.io Aug 02 '17 at 15:28
  • 8
    @zatziky - Geez. I gave you 8 reasons to use REST. If none of those apply, then stick with your webSockets - that's pretty much all there is to say. What the heck else do you want? You've provided absolutely NO requirements of any type (other than no push) so all this is a generic exercise to spout the differences between webSocket architecture and REST architecture. There's nothing else we can do. – jfriend00 Aug 02 '17 at 15:32
  • yes, you did wrote 8 reasons. As I wrote, we already use Websockets for some functionality, so for number 1, 2, 3, 4, 5, 6, 7 and even 8 we already have a solution. We have a REST/Websocket architecture. We just don't know when exactly use a REST request or WS SEND command to server. In none of the cases, we need a response but I don't see it as automatically pointing to WS. Maybea concrete example is more suitable: **Send message** to the chat. – Amio.io Aug 02 '17 at 15:38
  • @zatziky - If you already have a webSocket connection and the infrastructure to use it and make sure it's always connected and REST isn't offering you any specific feature advantages, then you can just decide which you prefer. As you appear to know, an already established webSocket connection is more efficient to use vs. making a REST call. But, it's really up to you. If there's no technical advantage driving you one or the other, it's totally up to you. There is no "right" or "wrong". Using an already established webSocket connection is likely more efficient. – jfriend00 Aug 02 '17 at 15:41
  • 3
    @zatziky - It sounds like you're expecting someone to tell you the "right" way to do it. There are reasons to pick one way over the other. If none of those reason compel you one way vs. the other, then it's just an architectural choice and you must take in the whole context of what you are doing and decide which architectural choice makes more sense to you. If you already have the reliably established webSocket connection and none of the advantages of REST apply to your situation then you can optimize for "efficiency" and send your data to the server over the webSocket connection. – jfriend00 Aug 02 '17 at 15:46
  • @zatziky - On the other hand, if you wanted there to be a simple API on your server that could be reached with an Ajax call from other clients, then you'd want your server to support this operation via REST so it would simplest for these other clients to carry out this one operation. So, it all depends upon which direction your requirements drive you and, if there is no particular driving reason to go one way or the other, you just make an architectural choice yourself. – jfriend00 Aug 02 '17 at 15:48
  • JFriend, your previous 2 comments are a much better answer to my question. :) I propose you to change your answer with these 2. I can upvote it. – Amio.io Aug 03 '17 at 11:57
  • @zatziky - I added those comments to my answer. – jfriend00 Aug 03 '17 at 20:00
  • Hey, JF, thank you. I have proposed an answer without your previous text. I hope you're fine with it. – Amio.io Aug 04 '17 at 06:23
  • 10
    @zatziky - No, I"m not accepting you removing all that helpful info from the answer so I rolled it back and I'm surprised that you were even allowed to just trash all that info. That is all useful info for all the other people that read this answer and whether you agree or not, it's all relevant to parts of your question. I don't understand why you're insisting on more edits. ALL the info is here. You know the answer. I've written it multiple times. It's clear to everyone. The additional data in the answer (before your edits) is useful to many. – jfriend00 Aug 04 '17 at 06:29
  • JF, I am not sure this the correct answer. I'll take time and accept if I am satisfied. Maybe I realize in future that your answer is correct. Sorry, for bothering you. Have a good day. – Amio.io Aug 04 '17 at 06:42
  • 3
    Definitely should not delete the previous answer. This is exactly what I was looking for while no other website has done it like this. – Chris Rahmé Oct 15 '21 at 14:07