4 ms·
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 resour
by almost 15y ago
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)
- csears 15y agoI 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?
- almost 15y agoFull 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 :)
- dalyons 15y agoI'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.
- almost 15y agoWhat'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 :)