Hacker News Reader

Comment by cagenut | Hacker News Reader

I get the basic idea, but when I try to flush it out into a full cluster and app design long-poll/web-sockets seems like a bit of a complexity nightmare on the back end. I mean you're taking a highly cachable stateless protocol and turning it into an uncachable one. Then you're taking a shared-nothing application layer and forcing it to do shared-state cache coherence via message passing. And all the way up and down the stack you're turning what was overwhelmingly treated as a request/response model and turning it into a different one. Every cache, proxy, application firewall, traffic shaper, loadbalancer and IDS on both sides is going to 'get confused' and net out to a toooon of user complaints and corner cases.

View on HN

There is no requirement to use polling or sockets. If it isn't relevant to your users or server side then don't do it.

But the bar now is that users expect their displays to automatically update promptly, and they don't care how hard it is for you to implement. You don't have to do the level of complexity you think. For example there is no need to tell the client there is an update, or the details of the update. All it needs to know is that there could be an update. It can then go off on the regular HTTP connections to see what is new/relevant and that will go via your existing servers/caches/load balancers etc.

Exactly. Ajax in general breaks REST, including bookmarking, caching, navigation and more. All major selling points of HTTP goes out the window. HTTP was created on top of TCP, but with severe restrictions to get the great features which HTTP is well-known for. Now someone re-lauches unrestricted TCP as a feature, when it is in fact much more simplistic and formed the base all along. Usage was purpously off limits due to the headaches that unrestricted client-server communication causes.

> Ajax in general breaks REST

Huh? You are supposed to correctly choose the HTTP verbs and URI path precisely so that HTTP semantics apply.

If you are talking about page state then there are numerous ways of dealing with that - one example is http://diveintohtml5.info/history.html

If your assertion is that developers can write bad code, abuse HTTP semantics, defeat caches, break navigation etc then so what? With the ability to do things right comes the ability to mess them up.

I've yet to see an RFC or standard that some developer somewhere didn't totally cock-up. :)

I'm wondering if bookmarking state would have made it into webapps had we not been forced to use HTTP because that is all that was available in the browser for years.

I am saying that by using Ajax to partially update a page, that updated page no longer has a URL which identifies it. This breaks HATEOAS badly. The idea of REST is that every state on a site has a representation. REepresentational State Transfer you know... So while there are many other ways of shooting yourself in the foot when designing a REST website, using Ajax makes it almost inevitable.

Reply on news.ycombinator.com