6 ms·

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 Hook

by bryanh 13y 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!

neilk 13y 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.
- yajoe 13y ago
  At the bottom of the page I saw: > An initiative by Zapier 2013. Zapier is a company that makes money off sites having REST endpoints to push and pull data. It looks like Zapier would prefer that more sites have endpoints to accept push, and this marketing effort is a brand-campaign (think Public Service Announcement) to get more people to tailor their products to work with Zapier. That explains why more emphasis was put on marketing, etc. The primary audience is not developers but PHBs and PMs to have sound bytes to parrot to developers. (I'm not cynical, I work in advertising, most of my products already have 'REST hooks'...)
  - bryanh 13y ago
    Bingo!
  - jqueryin 13y ago
    As I read through the website, I felt mislead by the title "REST Hooks - Stop the polling madness" in that I believed we were talking directly about reducing something like AJAX long polling for an alternative means of retrieving data from the backend. Having felt that pain before, and not opting for WebSockets yet, I was hoping for some kind of simple alternative. I have a portion of code that occurs during a registration process that is currently polling the backend for status updates as to the worker queue's progress (it's a lengthy registration with several moving pieces and calls to multiple remote APIs).
    - IanCal 13y ago
      Try playing with WebSockets, they're pretty easy to get going. Is there something about them keeping you away? Or would it require quite a re-architecture?
      - jqueryin 13y ago
        There's a lack of browser support (IE10+, no Android), and the fallbacks drain your mobile battery. It's just not quite there. I've done full presentations on WebSockets and toyed/demoed with it for a number of trivial and less than trivial applications, so I would like to think I'm more informed than most.
    - johnny22 13y ago
      server sent events? although they are push only. I can't tell if you also want write capabilities
- bryanh 13y ago
  Good point. For us (Zapier), we just waste a lot of time and resources polling. We talked to some of the SaaS services we integrate with and it is the same on their side as well. That is our motivation.
  - logvol 13y ago
    Ditto.
  - neilk 13y ago
    Great - if you're just up front about that I would read this. Then again if I'm not the audience, well, I guess you know what you're doing.
kristopolous 13y 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.
- singlow 13y ago
  I think they are just suggesting that services which are being polled frequently instead implement a rest-like subscription service which would accept an endpoint and then push the data to all of the subscribed endpoints when it changes. In many cases it is more work from the developers of those services but would reduce their bandwidth and server load immensely.
  - bryanh 13y ago
    This is a very good summary.
  - acjohnson55 13y ago
    Ohhh, so it's really a server-side technology to better consume third-party APIs. For whatever reason, this wasn't at all obvious to me. I had initially assumed that this was technology between client and server sides of a single-page application.
    - kristopolous 13y ago
      As did I. I've built these systems (socket-like systems that work efficiently across browser in diverse environments). And if you think you can just get that right the first time, then either you have the hacking skills of which I have never seen or you are (more likely) wrong. But this thing here they are talking about is something I've been doing for a long time. I didn't think about making a brochure site for it though. Just follow the principle of making the parts as dumb as possible. They should be the stupidest simplest things ever. Sometimes you can't get to this model on the first try, and that's ok. But the closer you get to it, the better the product becomes. I swear this is true and part of the soul of the machine's ghost. If you can't make things laterally connect this way, then make them vertically stack this way and then laterally connect this way. But don't obfuscate the objective.
deleted 13y ago
[deleted]
amenod 13y 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?
- shortcj 13y ago
  It would be interesting if browsers could accept HTTP requests.
- bryanh 13y ago
  There is no middle intermediary, its just two servers. For example, Facebook & your app. Instead of polling `facebook.com/api/posts` every 2/5/15/60 minutes, you'd set up a subscription for Facebook to ping you at `yoursite.com/hook.php`. The subscription would be managed under `facebook.com/api/subscriptions`.
unclebucknasty 13y 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 13y 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?

by bryanh 13y ago

neilk 13y 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.

yajoe 13y ago
At the bottom of the page I saw: > An initiative by Zapier 2013. Zapier is a company that makes money off sites having REST endpoints to push and pull data. It looks like Zapier would prefer that more sites have endpoints to accept push, and this marketing effort is a brand-campaign (think Public Service Announcement) to get more people to tailor their products to work with Zapier. That explains why more emphasis was put on marketing, etc. The primary audience is not developers but PHBs and PMs to have sound bytes to parrot to developers. (I'm not cynical, I work in advertising, most of my products already have 'REST hooks'...)
- bryanh 13y ago
  Bingo!
- jqueryin 13y ago
  As I read through the website, I felt mislead by the title "REST Hooks - Stop the polling madness" in that I believed we were talking directly about reducing something like AJAX long polling for an alternative means of retrieving data from the backend. Having felt that pain before, and not opting for WebSockets yet, I was hoping for some kind of simple alternative. I have a portion of code that occurs during a registration process that is currently polling the backend for status updates as to the worker queue's progress (it's a lengthy registration with several moving pieces and calls to multiple remote APIs).
  - IanCal 13y ago
    Try playing with WebSockets, they're pretty easy to get going. Is there something about them keeping you away? Or would it require quite a re-architecture?
    - jqueryin 13y ago
      There's a lack of browser support (IE10+, no Android), and the fallbacks drain your mobile battery. It's just not quite there. I've done full presentations on WebSockets and toyed/demoed with it for a number of trivial and less than trivial applications, so I would like to think I'm more informed than most.
  - johnny22 13y ago
    server sent events? although they are push only. I can't tell if you also want write capabilities
bryanh 13y ago
Good point. For us (Zapier), we just waste a lot of time and resources polling. We talked to some of the SaaS services we integrate with and it is the same on their side as well. That is our motivation.
- logvol 13y ago
  Ditto.
- neilk 13y ago
  Great - if you're just up front about that I would read this. Then again if I'm not the audience, well, I guess you know what you're doing.

kristopolous 13y 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.

singlow 13y ago
I think they are just suggesting that services which are being polled frequently instead implement a rest-like subscription service which would accept an endpoint and then push the data to all of the subscribed endpoints when it changes. In many cases it is more work from the developers of those services but would reduce their bandwidth and server load immensely.
- bryanh 13y ago
  This is a very good summary.
- acjohnson55 13y ago
  Ohhh, so it's really a server-side technology to better consume third-party APIs. For whatever reason, this wasn't at all obvious to me. I had initially assumed that this was technology between client and server sides of a single-page application.
  - kristopolous 13y ago
    As did I. I've built these systems (socket-like systems that work efficiently across browser in diverse environments). And if you think you can just get that right the first time, then either you have the hacking skills of which I have never seen or you are (more likely) wrong. But this thing here they are talking about is something I've been doing for a long time. I didn't think about making a brochure site for it though. Just follow the principle of making the parts as dumb as possible. They should be the stupidest simplest things ever. Sometimes you can't get to this model on the first try, and that's ok. But the closer you get to it, the better the product becomes. I swear this is true and part of the soul of the machine's ghost. If you can't make things laterally connect this way, then make them vertically stack this way and then laterally connect this way. But don't obfuscate the objective.

deleted 13y ago

[deleted]

amenod 13y 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?

shortcj 13y ago
It would be interesting if browsers could accept HTTP requests.
bryanh 13y ago
There is no middle intermediary, its just two servers. For example, Facebook & your app. Instead of polling `facebook.com/api/posts` every 2/5/15/60 minutes, you'd set up a subscription for Facebook to ping you at `yoursite.com/hook.php`. The subscription would be managed under `facebook.com/api/subscriptions`.

unclebucknasty 13y 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 13y 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?