The Argument for Real-Time REST APIs

http://blog.programmableweb.com/2013/03/05/the-argument-for-real-time-rest-apis/

by bryanh • 13 years ago

11 5 13 years ago

blog.programmableweb.com

bryanh2• 13 years ago

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.

deckyt2• 13 years ago

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• 13 years ago

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.

bryanh2• 13 years ago

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.

The Argument for Real-Time REST APIs

Related Stories