REST Hooks - Stop the polling madness

by qwertzlcoatl • 13 years ago

201 112 13 years ago

mikeknoop2• 13 years ago

Oh neat! We're launching resthooks.org today with several partners to promote an existing but underused real-time API pattern.

Here are more resources:

Intro: https://zapier.com/engineering/introducing-resthooksorg/

Why: http://resthooks.org/#why

Demo: http://demo.resthooks.org/

_lex• 13 years ago

I'm looking for a quick response to "How", w/o going through code. Care to enlighten me?

rcsorensen3• 13 years ago

http://resthooks.org/docs/ has a section titled "Minimum Implementation Walkthrough" that looks to be what you're looking for.

rcsorensen3• 13 years ago

This is neat. Similar in spirit to http://jsonapi.org .

Has any thought been given to the concept of supporting the same framework over something useful in a browser? http://resthooks.org/docs/alternatives/ lists some problems with the common methods, and rightfully so, but I don't see a different recommendation.

bryanh15• 13 years ago

We also wrote a quick drop-in Django application [0] (that plugs right into TastyPie if you have an API built on it) . We also have a sample CRM with a live API running [1]. Our friends at NetEngine wrote a sample Rails app [2], and our very own James wrote an awesome Node.js Sails app [3].

[0] https://github.com/zapier/django-rest-hooks

[1] http://demo.resthooks.org/

[2] https://github.com/net-engine/resthooks

[3] https://github.com/zapier/node-resthooksdemo

aantix• 13 years ago

Still scratching my head on the Ruby "reference" implementation. When I subscribe resource_subscriptions, who is receiving the update notification? Is the client side js code getting a push? Is the resource_subscriptions a long-polling endpoint? Not very clear at all.

bryanh15• 13 years ago

The server itself will just POST a payload to a defined URL. I'm not wildly familiar with the internals of that app or Rails in general, otherwise I'd give more detail!

zrail2• 13 years ago

I don't really understand what this is. Is this an attempt at a formalization of webhooks + JSON?

atonse• 13 years ago

Same here - I keep coming back to "are they just talking about webhooks? or are they also talking about some kind of persistent http streaming api?"

I'm thinking these are just Webhooks, but the REST part is throwing me off because I think of it more as a consumption concept (consuming resources, etc).

Update: Found this, which I think explained it best: "REST Hooks itself is not a specification, it is a collection of patterns that treat webhooks like subscriptions. These subscriptions are manipulated via a REST API just like any other resource. That's it. Really." - but it was in /docs, not the main page.

bryanh15• 13 years ago

Great call, we're adding it to the homepage now!

zrail2• 13 years ago

Oh, ok. That makes sense. I implemented that for Emma a few years ago but I don't know if I made it up or saw it somewhere else first. Probably the latter.

mikeknoop2• 13 years ago

Its not. Its promoting two things specifically:

1. Webhooks

2. A subscription layer via REST

Several major players already are doing this but it doesnt have a name.

REST Hooks are a way to consolidate that momentum and push it to a broarder audience.

bryanh15• 13 years ago

It is just a pattern around making traditional webhooks another resource on your existing REST API so you can programmatically control subscriptions/callbacks/webhooks/etc. instead of asking users to copy-paste URLs.

donpdonp2• 13 years ago

Thats what it appears to be, but on closer inspection it doesn't go that far. They give an example rest path of /subscriptions but i cant tell if its an example or meant to be used as a standard endpoint name.

annnnd• 13 years ago

Am I the only one who has trouble sifting through all this marketing? Even "read more" link leads to an article where half of the text promises what will be covered and another half talks about some subscriptions and how they are managed (they might have been mentioned in the first half, I agree - and I also read text only twice).

If someone has a better understanding of how this works, I would appreciate a TL;DR version for programmers (which are probably the target audience?). Thanks!

mcantrell2• 13 years ago

Here's my basic understanding of it: This sounds like webhooks, but they have a set payload, so that the server that is sent the webhook just calls the rest endpoint it is given in the payload.

carrja99• 13 years ago

Basically we're taking webhooks and adding a RESTful subscription layer to it. This way users don't have to go copy and past webhook urls into other applications... the applications they use automatically create and destroy the subscriptions for them.

afandian• 13 years ago

Agreed. I came here to ask if anyone actually understood anything about the product from the front page.

bryanh15• 13 years ago

We are pushing some copy updates to the homepage, most of the technical details were in docs. TL;DR coming to the homepage soon, but the gist is:

    REST Hooks itself is not a specification, it is a collection of patterns that
    treat webhooks like subscriptions. These subscriptions are manipulated via a
    REST API just like any other resource. That's it. Really.

Thanks for the feedback!

neilk2• 13 years ago

Better. That's practically the only thing that needs to be on the home page.

You also need to explain who you are and why you're doing this, too. Right now it looks like you have an interest in selling something but you never explain what it is. It reminds me a lot of those sites which sell some miracle product, and are deliberately very long and vague, and it ends finally with some button to order an ebook or something.

kristopolous2• 13 years ago

I have no idea how this solves the fundamental push/pull networking problem.

Is a network connection kept open? Is there an assumption that the user has some port open that can be contacted?

I see that you somehow reduced your calls, but I don't see how. Please tell me in actual socket level networking terms how this is done; who establishes a connection to what, for what, and for how long?

Also how do you deal with disconnects, timeouts, and missed realtime data.

amenod• 13 years ago

This is definitely better, but what I would expect is a short explanation of what happens to REST requests - why are there fewer of them? Are you caching the responses, serving them to clients (who are still polling, but they are polling you instead of the REST server) and waiting for PUSH request from server to invalidate the cache? Or is this a client-side solution too which allows a client to trigger a REST request only when data is available?

unclebucknasty2• 13 years ago

Why make effort to explicitly state that it's not a specification? That makes it more confusing, as it really is defining a standard interface for exposing and establishing Webhooks--i.e. pretty much a spec. So, when I read that it's not a spec, it made me question for a second whether I truly understood it.

I also agree with a previous commenter who said it's unclear what you guys' role is. Are you just defining this "spec" to help the world, and hoping that the world gets on board? Or, are you offering some sort of service? Also, how would a dev just start using these, when it requires that the services they are consuming "speak Rest Hook?". It just seems like a good idea, but not immediately useful. If there was a simple call to action that said, "Hey devs, let's all use these when building services", then the pitch would be more understandable (assuming that's what you guys are promoting).

BTW, I do think it's a worthwhile idea. Personally, I've found Webhooks to be very simple, thus I'm not really sold on the "research" that indicates devs struggle with them more than they would Resthooks. So, that's not the sell to me. It's having a standard, programmatic way of discovering Webhook availability and consuming them across various services/APIs that's the draw in my book.

Anyway, good luck.

jakehow• 13 years ago

This is how webhooks work in any API that has sufficiently embraced them (see Freshbooks for an example). Why are we pretending like this is something different?

spdy• 13 years ago

Same for me i miss the How? part.

And i got oversold on an idea that sounds good but i have no clue how it works.

http://en.wikipedia.org/wiki/Webhook

joeblau2• 13 years ago

You are not the only one. I read though it, clicked around, looked at the demos, thought about bookmarking it, got to the documentation page and saw this `/api/v1/subscription/`, thought That breaks HATEOAS then left.

I'm sure if I put more time into trying to understand what is going on I could figure it out, but to me, the message isn't that clear.

Kiro2• 13 years ago

How does it break HATEOAS?

dscrd• 13 years ago

I'm interested since my application publishes URLs just like that. What's wrong with it as far as HATEOAS is considered? How would it be better?

BetaCygni• 13 years ago

Did you actually use HATEOAS? I'm currently designing an API and it's just way too much work and overhead to add links when everyone is just going to hardcode them anyway. Do you have any examples where HATEOAS actually prevents or solves problems? Do you have any tips on how to get people to follow the links instead of hardcoding?

pbreit• 13 years ago

Yeah, it's pretty bad. I think it comes down to "assuming WebHooks, a suggested 'pattern' to set up the subscription programmatically".

mmgutz• 13 years ago

Agree with you. If the audience is developers, give it to us in black in white instead of some new jargon and marketing blah.

I looked through several pages (waste of time) and I still can't figure out how this is real time without websockets, polling, server side events. No way I would use this service if they don't know who their audience is.

nilliams• 13 years ago

Yep the missing part of the description is 'server-to-server', or 'client-with-a-listen-port (i.e. not a browser) to server'.

Unfortunately a lot of us developers see the term REST API and think a-ha, this is something I can consume in my browser. This isn't that, so confusion ensues.

crystaln• 13 years ago

And here I thought I was being dense.

Seems like it adds data that would normally be included in a poll response to requests that were going to be made anyway, and possibly adds requests that were normally going to be made independently to long polls, though I'm not sure about any of this.

If I am right, would be nice to explain this and how it compensates if there is not a "regular" request within a certain period of time. And well, to basically explain WTH REST hooks are....

Is the most important piece of information really: "REST Hooks itself is not a specification, it is a collection of patterns that treat webhooks like subscriptions"? That seems of tertiary importance at best. How about telling us what REST Hooks are and how they are that - not what they aren't from a marketing perspective.

This is targeting a technical audience. It shouldn't so drastically underestimate its readers.

mcantrell2• 13 years ago

This sounds like webhooks, but they have a set payload, so that the server that is sent the webhook just calls the rest endpoint it is given in the payload. Interesting idea, but it does sound like a regular webhook to me. That flow is the same way I use the Stripe webhooks for instance. I use the event id and make a call to Stripe directly, so that I can make sure the event is real.

donpdonp2• 13 years ago

In addition to webhooks, using a websocket connection to listen for streaming updates is a great way to eliminate polling.

dreen• 13 years ago

They are also easier to use and much more straightforward than hooks. And if you use something like Socket.IO the adoption of WS is irrelevant.

rcsorensen3• 13 years ago

Has anyone use PubSubHubbub ( http://en.wikipedia.org/wiki/PubSubHubbub ) for this pattern in the past? For straight subscriptions, it's always been compelling to think of the use cases being covered by PSHB and RSS.

steveklabnik5• 13 years ago

It is pretty fantastic.

julien2• 13 years ago

So, PubSubHubbub is not linked with RSS anymore and works with any type of data format, including JSON obviously :)

The quick win of PubSubHubbub compared to Resthook is that it has a 'security' mechanism in it, which means that the subscriber can be 100% sure that the service sending the notification is not someone impersonating it.

Aside from this, I feel like PubSubHubbub and Reshook solve the same problem: programatically setting up webhooks.

hcho• 13 years ago

Doesn't this assume that the API will only be used from a module living under a URL?

Most REST apis these days seem to be consumed form client side.

brian_cooksey2• 13 years ago

The focus is on server-server communication. A client like a web browser would need to use a different approach to get notifications, but there are options in that space besides polling.

Hovertruck2• 13 years ago

On average, 98.5% of polls are wasted

Erm. Is there a source for that?

jordanthoms2• 13 years ago

83% of statistics are made up on the spot.

andrewjshults• 13 years ago

A bit further down the page, they cite Zapier

"Over a representative time period, Zapier polled for changes 30 million times but only took action on 460,000 of those polls (1.5% efficient)."

Hovertruck2• 13 years ago

Ah, I must've missed that. Thanks!

bdcravens4• 13 years ago

It's a Zapier project, so they're citing themselves.

https://github.com/zapier/resthooks

derek1800• 13 years ago

Are there patterns for client side JavaScript to be notified of changes to REST resources? I don't believe this particular pattern applies if I understand correctly as it needs a URL to notify.

jordanthoms2• 13 years ago

I think you'd have to have your server receive the hook, and then notify the client side using websockets/long polling etc. Pusher makes that really easy.

bryanh15• 13 years ago

Websockets are still your best bet here.

aeon10• 13 years ago

It is awfully difficult to get a technical TL;DR version from a website, whose target audience is programmers. I think explaining what this does concisely and technically, preferably on the front page with code examples etc would be really useful.

derefr• 13 years ago

This sounds pretty much like the polyfill Socket.IO/SockJS do to create a socket atop polling-based transports.

steveklabnik5• 13 years ago

REST Hooks itself is not a specification, it is a collection of patterns that treat webhooks like subscriptions.

Bummer. No matter if you like it or not, a collection of patterns with a name _is_ a specification, just possibly a poorly defined one. See the confusion in this thread. If it were a link to a spec, nobody would be confused.

Skip the pedantic arguments about standards and implementation details

This reads to me as "everyone is going to have a slightly incompatible implementation. One library wont be good enough, I'll need to write a new one per site that uses this."

Furthermore, what about PubSubHubbub?

Finally, polling is great: Ive found few situations where it doesn't work well, people just tend to only do the most basic of implementations and blame polling. See http://roy.gbiv.com/untangled/2008/paper-tigers-and-hidden-d... for a really interesting example.

EDIT: numbers were real, added a supporting link

bryanh15• 13 years ago

Hey Steve!

See the confusion in this thread. If it were a link to a spec, nobody would be confused.

We definitely had a little confusion in the thread, I think that was mostly because we put too much marketing on the homepage for this audience, but the absence of a proper spec could have definitely contributed. We're correcting some of this.

This is all about adoption of some sort of subscription-based HTTP callback: at this point in time any flavor will do. We have no doubt that a formal spec will pop up someday (and that would make us very happy!).

Furthermore, what about PubSubHubbub?

PubSubHubbub always seemed a little heavy and was a departure from APIs that weren't XML/ATOM based (meaning most JSON API providers wouldn't touch it). Not saying I agree with it, but that is the feedback we got.

Finally, polling is great for 99% of use cases (I can make up statistics, too)

We posted the numbers driving our stats on the homepage. They are not made up and come straight for our Elasticsearch cluster. I'm happy to elaborate on them!

steveklabnik5• 13 years ago

Its true, thats a large part of the issue. If you put so many links to /doc om your homepage, well...

Even then, this page (/docs) barely says anything. Almost anything can be 'compliant,' because there's almost nothing to say. I really think some rigor would help a lot. I can appreciate not wanting to get into full RFC2119 right away, but you need some amount of description.

PuSH is not limited to a XML/ATOM, and companies like SuperFeedr use PuSH with JSON.

In fact, I'm pretty sure PUSH is 98% of a webhooks implemenation.

I didnt understand that the numbers were from anything real, my mistake and apologies.

technoweenie• 13 years ago

GitHub implements the PSHB subscription API. It's fine, but doesn't really fit in well with the rest of our JSON API. For instance, parameters are sent over as form encoded values like "hub.mode".

http://developer.github.com/v3/repos/hooks/#pubsubhubbub

We also have a regular JSON endpoint for our hooks resource (which is essentially a subscription API).

julien2• 13 years ago

Let's make it better :) The PubSubHubbub mailing list is still open and would welcome your comments on how to make things better!

lvh• 13 years ago

I don't agree with this part:

In other words, if everyone implemented REST Hooks, server load for both the sender and receiver could be reduced by 66x.

No, the number of requests could be reduced by a factor of 66. I'm not saying that's not impressive, I'm saying that the polling requests that ended up resulting in no action are cheaper than actionable requests, so, server load will go down by much less than a factor of 66x. The amount of work is the same, just busywork is less.

bryanh15• 13 years ago

That is a good point. What kills us the most is the latency on network IO when polling.

Kiro2• 13 years ago

After reading through all the comments here I still can't figure out what this is. Sorry.

city41• 13 years ago

This blog post should help, it helped me:

https://zapier.com/engineering/introducing-resthooksorg/

tkellogg• 13 years ago

This isn't impressive. [MQTT][1] is a much better protocol, and an open standard. It's a pub/sub that runs over TCP with variants that run over UDP & TLS. There's only a 2+ byte overhead, so it's very light. It's ideal for mobile devices because it has a QoS system built-in, so the developer doesn't have to think through the problem of missing messages where cell service is sub-optimal. MQTT is even resource-based, so it fits well with REST. I wish more people would start using MQTT instead of these crazy hacks like REST Hooks.

[1] http://mqtt.org/

jalfresi2• 13 years ago

I hate to be THAT guy but someone was going to say it so it may as well be me :)

This is a collection of patterns, right? Well why not make this really REST and rather than list a bunch of URL templates provide REL types for each of these like so:

REL subscriptions-list

nkoren• 13 years ago

Curious if anybody can answer a question for me. I've recently started building some apps with MeteorJS, and am having loads of fun with it. At first I'd been a bit suspicious of its magic pixie dust -- seemed too good to be true -- but so far it's done everything it promised, and has allowed me to focus on developing the parts of the app I care about. After checking briefly to see that my data syncing was genuinely low-latency and low-bandwith (which under every test I've subjected it to, it appears to be), I've pretty much forgotten about this level of engineering and have focused on bigger-picture stuff.

Which brings me to the question: should I care about something like REST Hooks? Is it a mistake to become complacent and assume that the lower-level infrastructure will Just Work? Or can MeteorJS (and presumably other high-level frameworks) be trusted to handle this kind of stuff in a way that makes it safe for me to forget about it?

Just curious what the esteemed HN denizens think about this, as I'm sure there are some strong and reasonably well-informed opinions out there...

1qaz2wsx3edc• 13 years ago

I think, if anything, Meteor proves it's possible that it can be the responsibility of the framework, not the developer.

jalfresi2• 13 years ago

I hate to be THAT guy but someone was going to say it so it may as well be me :)

This is a collection of patterns, right? Well why not make this really REST and rather than list a bunch of URL templates provide REL types for each of these like so:

REL subscriptions-list -> GET subscription-create -> POST subscription-read -> GET subscription-update -> PUT subscription-destroy -> DELETE

Now it doesn't matter what the URL structure is, I can pull the <link> elements from the page and be TOLD the URL, rather than follow a URL template. That way, this doesnt rely on out of band knowledge i.e this web page and its (poor) description.

jedberg• 13 years ago

Isn't this like SUP?

http://blog.friendfeed.com/2008/08/simple-update-protocol-fe...

tlrobinson• 13 years ago

Here's another (work in progress) spec for managing webhook/HTTP callback subscriptions: https://github.com/progrium/http-subscriptions/blob/master/S...

veesahni• 13 years ago

TL;DR - REST Hooks is an API pattern where the API provides an endpoint from which webhooks can be programmatically setup and removed.

prodigal_erik• 13 years ago

The docs talk about "event types" like contact.update which do not exist in HTTP and require knowing the semantics of a particular group of resources. To truly be RESTful, I would want "please notify me of any PUT, PATCH, or DELETE to this list of URLs, or POST creating a URL that matches this pattern." And if you're going to include a copy of the resource (I don't know what else a payload would be) you need the media type the subscriber expects as if you were doing content negotiation for a GET request from them. Or maybe the payload could just be the current result of a HEAD request so the subscriber can invalidate their caches, and they can send the appropriate GET request(s) when and if they care to.

There should be some standard link relation like <link rel="subscription"> so clients have some hint that this is available and where to request it.

I'd also want some way to manage the freshness/load tradeoff, like "please notify me within one hour but no more than every five minutes".

bdcravens4• 13 years ago

Why is this a thing? Your API interfaces with a message queue; your end client uses all the libraries and patterns built up over the years to consume from the queue. That doesn't sound all startup-y like "REST Hooks", but the pattern has been around for a long time.

bdcravens4• 13 years ago

The way the info is presented bugs me. The first "case study" is Zapier. Later, in the "Learn how..." set of links, Zapier is listed as one of many. Look to the footer, and the Github link, and it's of course evident it's a Zapier project.

This project (er hmm, "initiative") is core to Zapier's business. If every service out there had a hook atop their service, it'd make things a lot easier for Zapier. That's cool. What bugs me is the feeling that Zapier's branding in the whole thing is less than transparent.

It seems that open source projects are getting more and more marketing driven, and the way this "initiative" is packaged is a sign of things to come.

elliotanderson• 13 years ago

I don't see how a company being involved with this "initiative" affects the core concept - it's a net benefit for both API consumer and producer in moving to a subscribe/push model. Less requests, less load, closer to real time updates. Swap Zapier with any other consumer and the result is the same

bdcravens4• 13 years ago

Disclosure - had their name been at the top somewhere, and said "we" instead of "Zapier" it would boost the credibility of the project.

bialecki• 13 years ago

If for some reason you can't or don't want to implement webhooks, at least make sure you the GET endpoint for any object has a query param that supports fetching the most recently updated or created objects and supports pagination.

It sounds trivial, but you'd be surprised how many APIs don't support one or both of those features. When you're writing an API it might seem unnecessary to start (after all, who could ever have 1000s of <object>?), but if someone ends up polling your API frequently, having those two features can reduce a lot of unnecessary load for both you and the poller. And, of course, make sure you have an index on the created and/or updated dimensions.

That said, webhooks are terrific. Few things to consider when implementing them:

- Think carefully about the payload you send to the webhook. It's usually a good idea to send some related objects/data because many times when someone gets a webhook payload, that'll trigger calls to your API to get related information you could've reasonably sent them in the initial payload.

- You'll likely want to some way to keep track of errors so if an endpoint starts returning 404s or 500s you have a way to programmatically discard it after X failed attempts.

- In your docs, give sample, "real world" payloads developers can test against. It saves times over creating a RequestBin, pushing there, copying, cURLing, etc. (Remember, you can't set up a webhook to localhost.)

- A nice to have is some sort of retry capability with an exponential back-off. Servers go offline and if they get pushed webhook data then, those messages are lost. You could say, "tough, it's the consumer's responsibility," but if having all the data is important, most people will resort to polling. (Somewhat related, you'd be surprised how often the APIs of some larger SaaS companies are "offline" -- e.g. returning 503 --, so these things do happen.)

johns2• 13 years ago

You can send a webhook to localhost, just in a roundabout way using one of the local tunneling solutions: http://john-sheehan.com/blog/a-survey-of-the-localhost-proxy...

Great points though.

lojack• 13 years ago

While the paradigm of having a webhook makes more sense, I personally hate working with them. I've yet to see a graceful way of handling local development that doesn't involve localtunnel (or some alternative) and constantly having to un-register and re-register endpoints every time localtunnel gives you a new hostname. I understand the point and would prefer working with them if there was just a good way to handle local development.

bryanh15• 13 years ago

This is a great point, is there a better way to do local dev with webhooks? I always used localtunnel which is great it not perfect.

johns2• 13 years ago

Some other options here: http://john-sheehan.com/blog/a-survey-of-the-localhost-proxy...

I personally think you should be using one that gives you permanent URLs (ngrok or Passageway) but that also keeps a log when you're client is disconnected. I'm pretty sure only our Passageway does that.

harel• 13 years ago

Someone should show this to Facebook.... Just saying...

bradhe• 13 years ago

I have no idea what this is.

dpweb• 13 years ago

Powerful idea, should be made a specification. Simple enough too - what they describe is almost trivial to implement in /* insert your web framework of choice */. You wouldn't even need a library. Handle your HTTP verbs, store subscriber state, and call them out on events. It's nice.

andreineculau• 13 years ago

FWIW http://barelyenough.org/blog/2009/05/push-or-pull/ case closed

geuis• 13 years ago

I just want to point out that having read that entire page, I still have absolutely no idea what this is, how it works, etc.

I have a solution for polling. Its called websockets. Even more, there's a well-supported library called socket.io that transparently handles it for all browsers.

retrogradeorbit• 13 years ago

Give a man a hammer, everything looks like a nail. REST has become a bit of a hammer. The reason a lot of RESTful designed software I've seen has such poor performance is because REST is used like a hammer... everywhere! And whole bunch of places it's not needed and it's not ideal.

REST Hooks - Stop the polling madness

Related Stories