Hacker News Reader

Comment by almost | Hacker News Reader

Apples vs. Oranges: discuss!

(I'm quite happy with my RESTful API that allows subscription to resources via Websockets. This works very nicely when your resource representations include their own href)

View on HN

I had been thinking of something similar... Use WebSockets for pub-sub/broadcast notifications, but keep REST/XHR for all the normal request-reply operations. It seems like they could be very complementary.

In your API, does the WebSocket subscription deliver the full content of the updated resource? Or does it just provide a change notification which triggers a GET to pull the full content?

Full content. I have a layer over Backbone.JS on the client side that provides an identity map for models (all of which are identified by uri). When a representation is recieved it grabs the relevant model and updates it which makes any views listening on that model also update themselves in the normal backbone way. I think it's kind of neat :)

I've done exactly this before. It works really well. For endpoints that support it, you can put a subscription channel id in the normal REST resource. If the client sees the pubsub channel, and understands what to do with it, it can subscribe for updates via websockets; if it cant/chooses not to, if can just refresh the resource via standard http GET.

What's especially nice is Websockets have their own url type (ws://) you can just include a link to the Websocket's endpoint for the resource for the API client to follow. Reductions in the amount of custom stuff that has to be done is always good :)

Reply on news.ycombinator.com