Live data from Hacker News

You know how HTTP GET requests are meant to be idempotent?

twitter.com

301–310 of 313 posts

Re: You know how HTTP GET requests are meant to be idempotent?

#301
post #67

> "I threw the code together in minutes and was too lazy to spend another couple minutes figuring out POST." So it's not the vendor's problem then. They provide you with two ways to make a request. You have a choice to do it right, you didn't.

What's your point? Nobody said it was the vendor's problem except you.

Re: You know how HTTP GET requests are meant to be idempotent?

#302
I recently soldered a wire to my garage door opener on the wall and ran it to a relay and then to the pins on a raspberry pi. Knowing the state of the door is key because the opener is just a toggle. I also have my alarm system hooked up to the pi, so it checks the state before and after any request. Repeatedly asking it to open will open it, or return success of it already is. Same with close.

It took a bit of testing before I trusted it would all work the way I thought it would, but now I user it and don't even think about it, it just works and is handy to have.

Re: You know how HTTP GET requests are meant to be idempotent?

#303

Earlier quoted context omitted.

> I'm not saying it needs a universal client, just that it's the only real reason I can think of for including all of that. I already gave several examples of reasons why you would do it this way in my earlier comment. Why have we leapt from the garage remote example to a FitBit that tracks vehicle mileage? I don't see why you keep leaping to "it must handle everything everywhere". Stop thinking about handling everyt…

Okay - so to put my question in terms of the garage remote example, say the API offered is_open, open_door, and close_door functions. A "dumb" client that is configured by the server is going to include all three. Image a developer that only wants the UI to be a toggle that mimics an actual hardware button? That would require some a priori knowledge of what the API supports. The list of actions is perhaps useful for…

I've been diligent about HATEOAS links for years, but recently stopped bothering. They've never actually been used in practice. While the concept of a universal HATEOAS client has been around forever, there's no real world use case for them. The whole idea is a solution looking for a problem.

Re: You know how HTTP GET requests are meant to be idempotent?

#304

Earlier quoted context omitted.

I got just the thing for you: https://gist.github.com/hraban/10c7f72ba6ec55247f2d Every time you write some code you need to remember removing before commit, surround it with a comment containing "NOCOMMIT". With this script as a pre-commit hook, git will echo an error message and fail. E.g.: print("debug: ", myval) becomes: print("debug: ", myval) # NOCOMMIT I end up relying on this every day I program. Can't go bac…

Thanks! I'm not sure how easy it would be to put the git hook on all my machines though? I have a collection of laptops (and one desktop) that I work on and I often don't use the same machine for a few weeks :-/ I ended up using a "env.h" file... is there a C-equivalent of the PHP (?) .env file?

https://direnv.net Would be my recommendation

Re: You know how HTTP GET requests are meant to be idempotent?

#305
post #181

Earlier quoted context omitted.

I think there was a homepage with a "toggle" button, the toggle button redirected to /toggle. site.com/toggle then got added to his favorites by safari. So it wasn't loading the site with the button, but the site that the button redirects to.

Correct. Site now has a form and a button. /toggle now responds only to POSTs, and redirects back to /.

i must zsound so obtuse. How does redirection happen? If there is a web page with a button, then what is /toggle? Is it another web page on his site? Isnt a button some code in html on the index.html page?

Re: You know how HTTP GET requests are meant to be idempotent?

#306
post #114

Earlier quoted context omitted.

Adding Wi-Fi control to your garage door using a WeMos is not over-engineering. It's just a fun little weekend hack.

Over-engineering is what I did... - Raspberry pi - Open/close sensors on the garage door as well as the side-entry door - Camera pointed at the side entry door taking photos while it is left open - Push alerts to my phone if either door is opened between specific hours of the night (Break-ins to detached garages were huge in my neighborhood) - Voice controls from my fucking phone to open the door I sold the house oth…

That sounds really cool. One of the advantages of owning your house.

Re: You know how HTTP GET requests are meant to be idempotent?

#307
post #15

When I recently added 'click to unsubscribe' functionality to my emails, the URL got wrote out into some logs. Those logs got written to a Slack channel and Slack loves to click any link it sees. Oh, and it doesn't respect robots.txt. But all I saw was every member of my list clicking 'unsubscribe'. It took a good hour to figure out exactly what was going on. Idempotence is not the problem here, by the way. That just…

Aren't you allowed to have your "click to unsubscribe" button lead to a page with a button that does a POST that actually unsubscribes? I feel like I've seen that approach in use.

How about just having, near the unsubscribe link in the email, a link that says "click here to ignore up to one unsubscribe link press within two minutes of clicking this link", so that the automated process that clicked the unsubscribe link by mistake will also click that link.

The page in question could also have a "actually, I do want to unsubscribe, I just clicked the wrong link by accident" button as well, in case a human reader is confused.

---

Or, one link that says "unsubscribe immediately" and another that says "unsubscribe only after confirmation", and the first one unsubscribes immediately, unless they also click the second link immediately before or after, while the second link only unsubscribes them if they click a confirm button on the page?

---

Or, maybe the unsubscribe link could have a confirmation button, but would also have some javascript to confirm the unsubscribe after a few moments of the page being fully loaded (the button being used if they have javascript disabled, for example)

Re: You know how HTTP GET requests are meant to be idempotent?

#308

Earlier quoted context omitted.

Okay - so to put my question in terms of the garage remote example, say the API offered is_open, open_door, and close_door functions. A "dumb" client that is configured by the server is going to include all three. Image a developer that only wants the UI to be a toggle that mimics an actual hardware button? That would require some a priori knowledge of what the API supports. The list of actions is perhaps useful for…

I've been diligent about HATEOAS links for years, but recently stopped bothering. They've never actually been used in practice. While the concept of a universal HATEOAS client has been around forever, there's no real world use case for them. The whole idea is a solution looking for a problem.

I still am having a hard time with the concept.

Going back to the garage door example. Say I'm building a wifi opener. It's going to have one button that acts like a toggle, just like regular garage door openers. Press the button and the door opens. Press it again and the door closes.

In the firmware, it will contact the opener server and it can get a list of actions and endpoints. But if version 2 of the server changes the action name from open to door_open, then my button is broken even though I've diligently followed the HATEOAS model.

Re: You know how HTTP GET requests are meant to be idempotent?

#309

Earlier quoted context omitted.

I've been diligent about HATEOAS links for years, but recently stopped bothering. They've never actually been used in practice. While the concept of a universal HATEOAS client has been around forever, there's no real world use case for them. The whole idea is a solution looking for a problem.

I still am having a hard time with the concept. Going back to the garage door example. Say I'm building a wifi opener. It's going to have one button that acts like a toggle, just like regular garage door openers. Press the button and the door opens. Press it again and the door closes. In the firmware, it will contact the opener server and it can get a list of actions and endpoints. But if version 2 of the server chan…

Yeah, IMO the whole thing was a pie in the sky dream 20 years ago that we'd have magical APIs that automagically all work together in harmony by following HATEOAS links to do what they want. So it would be like the internet of APIs and a "universal client" would be the browser.

But what was misunderstood in that vision is that context can't readily be conveyed through some simplistic HATEOAS verbs. In the real internet of internets, with browsers and HTMLs, you have help links, positioning, colors, animations, highlighting, decades of UX research to help people understand what the various buttons do. HATEOAS was supposed to provide this in an automated way as a "browser for APIs", but ultimately the concept is far too simplistic to guide anything beyond an obvious CRUD model. And for an obvious CRUD model, well, it's unnecessary.

So anyway, that's my position after a decade of experience with it.

Re: You know how HTTP GET requests are meant to be idempotent?

#310
This garage door opening story reminds me of something that happened in the 50's. The first powerful comm satellites happened to use a frequency that garage doors used (no id codes then). Garage doors opened and closed by themselves. My grandmother had it happen to her.
Post reply on HN