3 ms·

I think that web apps will increasingly start using WebSockets for their APIs instead of HTTP. HTTP was originally designed for serving static files and it's ve

I think that web apps will increasingly start using WebSockets for their APIs instead of HTTP. HTTP was originally designed for serving static files and it's very good at that; it's also conveninent for file uploads. For exchanging data, however, the WebSockets protocol is slightly better in my opinion; maybe just better enough that developers might very slowly switch to it over time. There are several things which make WebSockets appealing: - No CORS issues. - Data can be pushed to clients in real-time (this goes well with reactive UIs). - No need to send headers with every call/response. - The server is aware of the client's presence (and can detect the exact moment when they go offline). WebSockets add a few extra challenges related to recovering from lost connections and rate-limiting but a lot of libraries and frameworks have already solved these problems. The main reason why HTTP might stick around for a very long time in the future is because HTTP REST APIs are extremely widespread and well understood.

callumjones 8y ago
The problem with WS is that is significantly more complex than HTTP when it comes to caching. With WS you can’t leverage a CDN hosted solution and instead would need some complicated CDN that is aware of state. I like HTTP because it just works, especially behind buggy corporate and mobile network firewalls.
- pas 8y ago
  You only cache GET responses, no? For those you don't need CORS anyway, and anything that's user specific should remain strictly between you and the user, right? (And for that WSS is perfect.)
  - al2o3cr 8y ago
    > For those you don't need CORS anyway CORS is needed for GET if the request needs to send headers like `Authorization`, AFAIK
    - lostcolony 8y ago
      Yes. There are a few safelisted headers (and relatedly, content-types) that do not trigger a pre-flight; any GET that uses something outside of them (such as 'authorization") gets preflighted.
    - mr_toad 8y ago
      Yes, here’s a full list https://developer.mozilla.org/en-US/docs/Glossary/Forbidden_header_name https://developer.mozilla.org/en-US/docs/Glossary/Forbidden_...
chrismorgan 8y ago
> - Data can be pushed to clients in real-time (this goes well with reactive UIs). You’ve been able to do that for many years with server-sent events. > - The server is aware of the client's presence (and can detect the exact moment when they go offline). You are overly optimistic in saying “exact moment”. You can probably detect when they probably go offline to within a minute, depending on various configuration factors, but they could then immediately come online again anyway. This much being said: JMAP (https://jmap.io/ https://jmap.io/), an RPC and object syncing protocol sponsored by FastMail and approaching finalisation in the IETF, has used regular HTTP and server-sent events, but one of us has also been prototyping and writing a draft for JMAP over WebSockets; see https://datatracker.ietf.org/doc/draft-murchison-jmap-websocket/?include_text=1 https://datatracker.ietf.org/doc/draft-murchison-jmap-websoc..., the introduction of which also lists two more key benefits of using a persistent connection for the transport: authentication only needs to be done once, and that request bodies can be compressed too. (In conjunction with the whole HTTP/2-and-WebSocket incompatibility matter, I initially informally opposed the effort as needless fragmentation, but when these benefits were pointed out and also that WebSockets will soon work over HTTP/2, I retracted my objections: there are clear and concrete benefits of WebSockets over plain HTTP/2—though they’re admittedly mostly not quite ready yet.)
loevborg 8y ago
In most applications, replacing HTTP with WebSockets is a big mistake. HTTP is cachable, can be proxied, inspected via curl and examined in Chrome's devtools. More importantly, typical app communication with the server has request-response shape. If you're communicating over a WebSockets connection, that doesn't change the natural shape of your queries. So you have to correlate requests and responses and multiplex over the connection - essentially reimplementing HTTP, but poorly! If you have the choice, request-response communication is preferrable because it's always going to be simpler than bidirectional communication. If server push is an important part of your user experience, implement it as an addition to your HTTP routes and as a completely separate pathway (and consider using SSE instead of WebSockets).

callumjones 8y ago

The problem with WS is that is significantly more complex than HTTP when it comes to caching. With WS you can’t leverage a CDN hosted solution and instead would need some complicated CDN that is aware of state. I like HTTP because it just works, especially behind buggy corporate and mobile network firewalls.

pas 8y ago
You only cache GET responses, no? For those you don't need CORS anyway, and anything that's user specific should remain strictly between you and the user, right? (And for that WSS is perfect.)
- al2o3cr 8y ago
  > For those you don't need CORS anyway CORS is needed for GET if the request needs to send headers like `Authorization`, AFAIK
  - lostcolony 8y ago
    Yes. There are a few safelisted headers (and relatedly, content-types) that do not trigger a pre-flight; any GET that uses something outside of them (such as 'authorization") gets preflighted.
  - mr_toad 8y ago
    Yes, here’s a full list https://developer.mozilla.org/en-US/docs/Glossary/Forbidden_header_name https://developer.mozilla.org/en-US/docs/Glossary/Forbidden_...

chrismorgan 8y ago

> - Data can be pushed to clients in real-time (this goes well with reactive UIs). You’ve been able to do that for many years with server-sent events. > - The server is aware of the client's presence (and can detect the exact moment when they go offline). You are overly optimistic in saying “exact moment”. You can probably detect when they probably go offline to within a minute, depending on various configuration factors, but they could then immediately come online again anyway. This much being said: JMAP (https://jmap.io/ https://jmap.io/), an RPC and object syncing protocol sponsored by FastMail and approaching finalisation in the IETF, has used regular HTTP and server-sent events, but one of us has also been prototyping and writing a draft for JMAP over WebSockets; see https://datatracker.ietf.org/doc/draft-murchison-jmap-websocket/?include_text=1 https://datatracker.ietf.org/doc/draft-murchison-jmap-websoc..., the introduction of which also lists two more key benefits of using a persistent connection for the transport: authentication only needs to be done once, and that request bodies can be compressed too. (In conjunction with the whole HTTP/2-and-WebSocket incompatibility matter, I initially informally opposed the effort as needless fragmentation, but when these benefits were pointed out and also that WebSockets will soon work over HTTP/2, I retracted my objections: there are clear and concrete benefits of WebSockets over plain HTTP/2—though they’re admittedly mostly not quite ready yet.)

loevborg 8y ago

In most applications, replacing HTTP with WebSockets is a big mistake. HTTP is cachable, can be proxied, inspected via curl and examined in Chrome's devtools. More importantly, typical app communication with the server has request-response shape. If you're communicating over a WebSockets connection, that doesn't change the natural shape of your queries. So you have to correlate requests and responses and multiplex over the connection - essentially reimplementing HTTP, but poorly! If you have the choice, request-response communication is preferrable because it's always going to be simpler than bidirectional communication. If server push is an important part of your user experience, implement it as an addition to your HTTP routes and as a completely separate pathway (and consider using SSE instead of WebSockets).