0

I am currently implementing front-end part of the collaborative application requiring two-way live communication between server and the web app. Cloud service responsible for the data exchange will be made by other team.

Other team insists that for the data coming to the web app they will open WebSocket connection but only for notifying client about data change on the server, and then app will request this changed data using REST GET separately. User changes in the app would be sent out also using REST.

It seems to me as a redundant to use both REST and WebSockets, and my instinct tells me to just pass the actual data using only WebSocket both ways.

Am I missing something? Is there some technical limitation why it would be a good idea to design the flow like they want to?

Improve this question
6
  • 2
    It makes less work for them, otherwise they have to support the data request both from the WebSocket and from the web API. I don't think it would necessarily be difficult to set it up to use a common request and response format, but the effort level isn't zero.
    – Craig
    Commented Jun 13 at 19:24
  • 1
    @Craig I am afraid I don't understand. It would be less work for them to send notifications with the id's of changed items, and then to support separate api returning data represented by those id's? The complexity of the solution was not mentioned, only performance concerns.
    – helloFromTheOtherSide
    Commented Jun 13 at 20:00
  • 1
    Rest is easier to use out of the box. You may end up creating something similar to rest using web sockets.
    – Ccm
    Commented Jun 13 at 20:35
  • When Web sockets are used for client notifications only, and REST/Http for data transfer only, it sounds to me there will be a clear separation of concerns, no redundancy. So why not give it a try?
    – Doc Brown
    Commented Jun 14 at 4:23
  • 1
    More complicated WebSocket use cases are difficult to do well. Suddenly you have to think about things like errors and content types and caching. This often ends with the WebSocket turning into a custom RPC protocol with some HTTP-ish features. Unless latency is really important, making a separate request using HTTP is going to be much easier for everyone involved. Sending change notifications (without content) is also a common pubsub pattern where bandwidth is constrained or where the full content might not always be needed.
    – amon
    Commented Jun 14 at 15:42

1 Answer 1

Reset to default
4

This is probably best answered by the team building the application, but here are some considerations that I can think of:

  • REST services are pretty easy to build. Lots of frameworks exist in every tech stack that facilitate development, testing, and deployment. They may have started with REST services.
  • REST services are also easier to reuse. The HTTP protocol is easier to handle. Besides, web sockets are more geared towards browser-based applications. REST services can be used by browser applications, web APIs, microservices, mobile apps — pretty much anything built with technology that has an HTTP client. Which is basically every tech stack today.
  • Web sockets are a different protocol, and a different way of programming. Web sockets might have been offered after the REST services were built. This becomes an economic decision. It would require additional investment to support a two-way socket connection, which might not have been worth the effort.
  • Furthermore, web sockets might not have been meant as a fully featured service. The use case might have been purely for notifications, with all business operations going through the REST services. Here again, the motivation is probably to simplify maintenance and development.

It seems to me as a redundant to use both REST and WebSockets, and my instinct tells me to just pass the actual data using only WebSocket both ways.

Am I missing something?

You might be underestimating the effort required to support their business operations from both a REST interface and web sockets. They involve different programming frameworks and different problems. Each interface would need to be fully tested, and that is a significant amount of work for even medium-sized applications.

Because the effort is so high, it is difficult to discuss technical limitations without also discussing time and money. The logic to handle an HTTP request and response is vastly different than for handling messages over a persistent connection. This difference in protocols is a technical limitation, which translates to more development time, which costs more money.

GeeksForGeeks.org has a good write-up about the differences between HTTP and web sockets, including the use cases for each. That might be a good place to start.

Unfortunately, an in-depth comprehensive answer to your question is not possible without knowledge of this company's history, their product priorities, and technology roadmap. Strangers on the Internet won't have this knowledge.

Improve this answer

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