The Argument for Real-Time REST APIs(blog.programmableweb.com)
blog.programmableweb.com
The Argument for Real-Time REST APIs
http://blog.programmableweb.com/2013/03/05/the-argument-for-real-time-rest-apis/
1 comments
Hi Bryan,
Enjoyed your post. First-time posting here on HN so pardon any noobish remarks that follow ... I definitely like the idea of exposing webhook/subscriptions via REST in this way. Do you have any thoughts on how rich client-side apps (e.g. a Backbone app) could get the real-time benefits of such an API? It's my understanding that real-time updates will be POST-ed to a user-defined hook URL, presumably hosted on a server that is maintained by the API consumer. Maybe I've got it all wrong?
Thanks again for your post.
Enjoyed your post. First-time posting here on HN so pardon any noobish remarks that follow ... I definitely like the idea of exposing webhook/subscriptions via REST in this way. Do you have any thoughts on how rich client-side apps (e.g. a Backbone app) could get the real-time benefits of such an API? It's my understanding that real-time updates will be POST-ed to a user-defined hook URL, presumably hosted on a server that is maintained by the API consumer. Maybe I've got it all wrong?
Thanks again for your post.
Sorry for the late reply!
REST Hooks aren't really designed for browser consumption, you literally need a persistent connection to the browser to handle this.
For a quick example of a solution you could build: consider a Node server with Socket.IO. The client would work just like normal consuming REST APIs that return JSON, but the websocket would be an additional way to "update" the a Model or Collection in realtime.
Perhaps something like Redis' PUBSUB would work as the core mechanism (perhaps in your PHP/Python/Ruby app you'd save to the db, ping PUB into Redis, the Node instance would SUB out the message and send it to any clients). I am sure you could get sub-second reaction times this way.
REST Hooks aren't really designed for browser consumption, you literally need a persistent connection to the browser to handle this.
For a quick example of a solution you could build: consider a Node server with Socket.IO. The client would work just like normal consuming REST APIs that return JSON, but the websocket would be an additional way to "update" the a Model or Collection in realtime.
Perhaps something like Redis' PUBSUB would work as the core mechanism (perhaps in your PHP/Python/Ruby app you'd save to the db, ping PUB into Redis, the Node instance would SUB out the message and send it to any clients). I am sure you could get sub-second reaction times this way.
A great way to get webhooks to the client is through some sort of real-time push service. Either homegrown or something like Pusher. You'd have to listen at a webhook endpoint then re-create the event in Pusher, but the client would be simple. Pusher might even support creating the event directly from a webhook, I can't recall.
If you don't want to maintain the webhook listener, create a script on webscript.io to listen and create the Pusher event.
If you don't want to maintain the webhook listener, create a script on webscript.io to listen and create the Pusher event.
Nice suggestions. I'll have to give Pusher a try one of these days. I've actually worked with the homegrown approach before, having my client connect to websocket endpoints that subscribe them to a redis channel where real-time updates are published as events occur within the system.
One thing that's often bothered me about that approach is how I've handled both websocket and RESTful HTTP endpoints from a single server. The solution mentioned by OP could go some way to allowing me to move the websocket/push handlers off to a dedicated server. This 'push server' might consume the REST API exposed by my HTTP server to set up webhooks. It could then forward information coming in on the hooks to the client, using some push mechanism, be that websockets, Pusher, whatever.
Thanks for your reply :)
One thing that's often bothered me about that approach is how I've handled both websocket and RESTful HTTP endpoints from a single server. The solution mentioned by OP could go some way to allowing me to move the websocket/push handlers off to a dedicated server. This 'push server' might consume the REST API exposed by my HTTP server to set up webhooks. It could then forward information coming in on the hooks to the client, using some push mechanism, be that websockets, Pusher, whatever.
Thanks for your reply :)
It definitely has its drawbacks (mainly that there is no ubiquitous specification) but the advantages are most folks already have a heavily used REST API, and we already have lots of variation in REST so its nothing particularly jarring.
I'd love to hear thoughts on this though.