Why are we still using HTTP instead of WebSockets to build web applications?

Question

I recently dived into the WebSockets theme and created a small application that uses them.

Now I wonder why the HTTP API is still in use, or rather, why they are still being offered.

As far as I can see, I can do nothing with WS, which would be possible through HTTP, but, on the contrary, I get many improvements.

What will be a real-world example of an application that benefits more from an HTTP powered firewall than from WS?

Answer 1

@ Julian Reshke made good points. The web is document-based, if you want your application to play on the WWW ... it must comply with the rules of the game.

However, you can create WS-based WS applications that meet these requirements.

• Using the HTML5 History API, you can change the URL displayed by the browser without causing navigation . This allows you to have a different URL in the address bar depending on the state of your application, then allowing bookmarks and page history. The "ui-router" plugin for AngularJS plays very well here, changing the URL if you change the state programmatically and vice versa.

• You can do a scan of your SPA .

But you still want to use HTTP for some other things, such as getting resources or views and caching them using HTTP caching mechanisms. For example, if you have a large application, you want some large views to load on demand, rather than packaging everything in a large main view.

It would be painful to implement your own caching mechanism for HTML to get views and cache them in local storage, for example. In addition, using traditional HTTP requests, these views can be cached in CDN and other proxy caches.

Websockets are great for supporting “connected” semantics, sending data with a slight delay, and pushing data from the server at any time. But a traditional HTTP request is still better suited for operations that can benefit from distribution mechanisms such as caching, CDN, and load balancing.

About the REST API and the WebSocket API (I think your question was actually about that), this is more convenience than preference. If your API has a higher connection call speed ... a website probably makes more sense. If your API receives a low call speed, it makes no sense to use WebSocket. Remember that a connection to Websocket, although it is lightweight, means that something is being held on the server (that is: the state of the connection), and this can be a waste of resources if the speed of the request does not justify it.

Answer 2

Bookmarking? Page History? Caching Search engine visibility?

Answer 3

HTTP and WebSockets are two web-based tools designed to perform various tasks. With HTTP, you typically implement a request / response paradigm. With WebSockets, you typically implement an asynchronous real-time messaging paradigm.

There are several applications in which you need paradigms.

You can also try using WebSockets for request / response and use HTTP for an asynchronous real-time messaging paradigm. Although the former makes little sense, the latter is a widespread method necessary in all cases when WebSockets do not work (due to network intermediaries, lack of client support, etc.). If you're interested in this topic, check out this other answer of mine, which tries to clarify the terminology associated with these methods: Is Comet deprecated now with Server-Sent Events and WebSocket?