Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebSockets versus REST?

infoq.com

Post reply on HN
Print view View original

11–20 of 60 posts

Re: WebSockets versus REST?

#11

Post by Nitramp »

prodigal_erik wrote: post #4

If anything, this is understating the problem that authors just aren't doing the design work to provide addressable, reusable resources to the rest of the world. They either haven't noticed or don't care that siloed javascript apps are destroying the web.

I think both can coexist. WebSockets, common comet long poll, and even the "internal" AJAX APIs of web applications are one thing, addressable URIs to resources another.

E.g. Gmail has history navigation and bookmarkable URIs for emails, but no such thing for chat or other page state, which is totally fine.

REST with its addressable resources has clear advantages over RPC style apps for many applications, it won't go away. Bookmarks, navigation, the overall simplicity.

Re: WebSockets versus REST?

#12

Post by hello_moto »

farhanpatel wrote: post #3

I belive that this is the future. With things such as Backbone.Sync written to communicate with websockets(via Socket.io). We can Keep Backbone models in sync easily. https://github.com/logicalparadox/backbone.iobind Fog Creek's new Trello syncs data using websockets as well. Its quite effective and works well. Trello also falls back to a regular short-polling system if it needs to.

It's 2012 and we just finished a project using SOAP, within budget and time-frame, and the client is more than happy.

No, I refuse to believe the future is determined by some cool startup.

Re: WebSockets versus REST?

#13

Post by drawkbox »

udp wrote: post #9
javascriptlol wrote: post #6

Earlier quoted context omitted.

Unfortunately, during our circle back to the 1970's we lost UDP, which is essential for real time protocols.

Exactly. Flash sockets are TCP only (proprietary Adobe protocols aside), and it seems WebSockets ended up without any UDP support either. The overhead of TCP is just ridiculous when you're trying to implement real-time game movements with dead reckoning, etc.

Unity has UDP sockets and yes all good games that require fast real-time action need UDP. Adobe had it partially in their latest Flash Media Server RTMFP protocol but it was very limited.

RUDP or Reliable UDP is the best of both.

Here's some great info on UDP vs TCP and only using one or the other:

UDP vs TCP http://gafferongames.com/networking-for-game-programmers/udp...

Characteristics of UDP Packet Loss: Effect of TCP Traffic http://www.isoc.org/INET97/proceedings/F3/F3_1.HTM

Re: WebSockets versus REST?

#14

Post by hello_moto »

udp wrote: post #9
javascriptlol wrote: post #6

Earlier quoted context omitted.

Unfortunately, during our circle back to the 1970's we lost UDP, which is essential for real time protocols.

Exactly. Flash sockets are TCP only (proprietary Adobe protocols aside), and it seems WebSockets ended up without any UDP support either. The overhead of TCP is just ridiculous when you're trying to implement real-time game movements with dead reckoning, etc.

I think people would probably build their own communication protocol on top of UDP but not at the level of TCP, if they were given UDP support.

I'm not saying that's good or bad.

Back in college on a distributed systems course, one of the projects was exactly to build that because the professor wanted to produce somewhere between UDP (more than) to TCP (less than).

Re: WebSockets versus REST?

#16

Post by zaphoyd »

hengli wrote: post #7

http://stackoverflow.com/questions/6806263/websocket-api-to-... One of the main practical problems is that websockets take a second or 2 to start up, clearly too slow.

Where does this article talk about >1s connect times for websocket? The websocket handshake is a single network round trip (discounting any added by TLS if you are using it) and the initial client message frames can be sent in the same TCP packet as the handshake. A websocket connection should not add any more latency than HTTP(S) connections.

Re: WebSockets versus REST?

#17

Post by waffle_ss »

drawkbox wrote: post #13
udp wrote: post #9

Earlier quoted context omitted.

Exactly. Flash sockets are TCP only (proprietary Adobe protocols aside), and it seems WebSockets ended up without any UDP support either. The overhead of TCP is just ridiculous when you're trying to implement real-time game movements with dead reckoning, etc.

Unity has UDP sockets and yes all good games that require fast real-time action need UDP. Adobe had it partially in their latest Flash Media Server RTMFP protocol but it was very limited. RUDP or Reliable UDP is the best of both. Here's some great info on UDP vs TCP and only using one or the other: UDP vs TCP http://gafferongames.com/networking-for-game-programmers/udp... Characteristics of UDP Packet Loss: Effect of…

RUDP sounds very weird... why would you use it instead of TCP? At a glance, it looks like the only difference is RUDP doesn't enforce packets being received in-order (being a message-based protocol), while TCP does (being a stream-based protocol).

Re: WebSockets versus REST?

#18

Post by [deleted] »

andrewvc wrote: post #2

So, in a nutshell, we're seeing a swing back to RPC. I think that's great, bidirectional RPC is much nicer than REST. REST is great, but a good portion of the time proper rest begins to feel like square peg round hole, that's why we see endless discussions of 'proper' rest.

[deleted]

Re: WebSockets versus REST?

#19

Post by wavephorm »

prodigal_erik wrote: post #4

If anything, this is understating the problem that authors just aren't doing the design work to provide addressable, reusable resources to the rest of the world. They either haven't noticed or don't care that siloed javascript apps are destroying the web.

My experience tells me that WebSockets will absolutely dominate in web apps using private API's. They're just so much easier to work with, and superior performance. But REST will still be the preferred way to build public API's because Websockets require a certain amount of resource per user that you probably don't want in a public API.

Re: WebSockets versus REST?

#20

Post by icebraining »

andrewvc wrote: post #2

So, in a nutshell, we're seeing a swing back to RPC. I think that's great, bidirectional RPC is much nicer than REST. REST is great, but a good portion of the time proper rest begins to feel like square peg round hole, that's why we see endless discussions of 'proper' rest.

bidirectional RPC is much nicer than REST.

I don't see why - REST seems extremely elegant to me.

In any case, they solve completely different problems. REST is a set of constraints that ensure your architecture will be scalable, reliable, efficient (by allowing multiple levels of caching), easy to evolve (by being extremely decoupled) and linkable.

WebSockets throw away all that to ensure you can have low latency realtime bidirectional communications.

Post reply on HN