Websocket vs REST when sending data to server

by

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.

More Related Contents:

  1. RESTful Authentication
  2. RESTful URL design for search
  3. What are best practices for REST nested resources?
  4. What is the proper REST response code for a valid request but an empty data?
  5. websocket vs rest API for real time data? [closed]
  6. HTTP response code for POST when resource already exists
  7. Security of REST authentication schemes
  8. How to make remote REST call inside Node.js? any CURL?
  9. REST Complex/Composite/Nested Resources [closed]
  10. Best practice for partial updates in a RESTful service
  11. Groovy built-in REST/HTTP client?
  12. Transactions across REST microservices?
  13. Unable to upload zip file through karate framework
  14. API pagination best practices
  15. How to use cURL to send Cookies?
  16. What’s the best RESTful method to return total number of items in an object?
  17. Querystring in REST Resource url
  18. How to construct a REST API that takes an array of id’s for the resources
  19. Firefox Add-on RESTclient – How to input POST parameters?
  20. Spring @ExceptionHandler does not work with @ResponseBody
  21. Spring 4 RestController JSON: characteristics not acceptable according to the request “accept” headers
  22. Update an entire resource collection in a REST way
  23. What are the best/common RESTful url verbs and actions?
  24. Should I use Singular or Plural name convention for REST resources?
  25. Restful way for deleting a bunch of items
  26. Is it correct to return 404 when a REST resource is not found?
  27. When is it appropriate to respond with a HTTP 412 error?
  28. How to do a PUT request with cURL?
  29. What REST PUT/POST/DELETE calls should return by a convention?
  30. Get/post to RESTful web service

Leave a Comment