

The Argument for Real-Time REST APIs - bryanh
http://blog.programmableweb.com/2013/03/05/the-argument-for-real-time-rest-apis/

======
bryanh
Author here, happy to answer questions. At Zapier we've seen lots of
suggestions/specs for HTTP subscriptions, webhooks, and more but it seems the
most obvious way to enable real-time in API is via another simple REST
resource the encapsulates webhook/subscriptions.

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.

~~~
deckyt
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.

~~~
johns
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.

~~~
deckyt
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 :)

