Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

REST Hooks - Stop the polling madness

resthooks.org

Post reply on HN
Print view View original

111–117 of 117 posts

Re: REST Hooks - Stop the polling madness

#111

Post by IanCal »

jqueryin wrote: post #81
yajoe wrote: post #37

Earlier quoted context omitted.

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…

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 regist…

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?

Re: REST Hooks - Stop the polling madness

#112

Post by BetaCygni »

joeblau wrote: post #45
annnnd wrote: post #8

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 ver…

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.

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?

Re: REST Hooks - Stop the polling madness

#113

Post by johnny22 »

jqueryin wrote: post #81
yajoe wrote: post #37

Earlier quoted context omitted.

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…

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 regist…

server sent events? although they are push only. I can't tell if you also want write capabilities

Re: REST Hooks - Stop the polling madness

#114

Post by dmak »

acjohnson55 wrote: post #95
singlow wrote: post #62

Earlier quoted context omitted.

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.

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.

Thats what I thought too.

Re: REST Hooks - Stop the polling madness

#115

Post by bdcravens »

elliotanderson wrote: post #106
bdcravens wrote: post #76

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. W…

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

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

Re: REST Hooks - Stop the polling madness

#116

Post by jqueryin »

IanCal wrote: post #111
jqueryin wrote: post #81

Earlier quoted context omitted.

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 regist…

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?

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.

Re: REST Hooks - Stop the polling madness

#117

Post by joeblau »

BetaCygni wrote: post #112
joeblau wrote: post #45

Earlier quoted context omitted.

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.

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?

The last API that I wrote used versioning in the headers and it saved us a ton of headaches when we updated our API. Our V2 upgraded some JSON fields of the API and our users who were on V1 were never affected. The funny the whole concept is that, you use it every day without even thinking about it. If you think about the web when you're looking at an PDF; What tells you if what version of the PDF file it is? Not the URL, it's the meta-data in the PDF tells you. You'll never see a link like:

  server.com/files/a-cs3/important.pdf
  server.com/files/a-cs4/important.pdf
  server.com/files/a-cs5/important.pdf
You'll see

  server.com/files/important.pdf
The information about the version of that pdf is contained in the document and managed document itself. What this allows for is you updating the PDF in any PDF editor without breaking how everyone else on the internet will process the file. You can edit the pdf with anything, re-save it and not break older version. This is the same concept that you should use to extend an API. If you think of the API as an document for a version of DATA (Just like any file/image is an endpoint), it will help you get a better grasp of why you shouldn't version in URL's.

Here is a more accurate description of the how you should design a REST API from the Author of the HTTP spec: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...

Post reply on HN