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

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

twitter.com

Post reply on HN
Print view View original

191–200 of 313 posts

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

#191

Post by luma »

chaosmonkey wrote: post #182
notheguyouthink wrote: post #148

Earlier quoted context omitted.

> Idempotence is not the problem here, by the way. That just means calling the method twice has the same effect. But GET should have no side-effect, in an ideal world. Of course, in the case of unsubscribe links, it needs to have a side-effect to comply with the law. Thank you! I felt like I was taking crazy pills with my understanding of idempotence. Calling GET /door/open is idempotent too, but it's still gross in…

I think he only had GET /door/toggle, which cannot be idempotent.

He mentions later in the thread that he doesn't have a sensor to indicate door position, which is going to kill this project and absolutely prevents an idempotent approach. There are a bunch of ways to approach this, most of which are patented by Chamberlain, which is the specific reason you don't find many garage automation solutions sold as a bundle in the US.

Typical bolt-on solutions would be a range finder pointing down from the ceiling near the door which can tell if the door is obstructing it, a tilt sensor mounted to the top door panel, or limit switches on the carriage way/tracks. With a door position sensor in place a simple momentary-contact dry relay can be used to trigger door motion.

Once that is in place, you can add another WeMos D1 mini to your car to open and close the door with no interaction: https://github.com/aderusha/MQTTCarPresence

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

#192

Post by criddell »

Can_Not wrote: post #160
criddell wrote: post #149

Earlier quoted context omitted.

> A single step, a button push, to confirm an unsubscription is fine. No, it really isn't. Lots of mailing lists operate exactly as the person you replied to mentioned where after unsubscribing you are given a chance to undo that action. That's a far more respectful way to operate.

The user isn't going to see the "Oops! I need to undo" button when their email client helps themself behind the scenes.

Yet somehow lots of places use the click-one-link-to-unsubscribe method and it seems to work. What are they doing differently?

The follow up confirmation screen feels slimy to me like some kind of cable company retention tactic. That's why I called it a dark pattern.

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

#193

Post by matte_black »

olavk wrote: post #179
matte_black wrote: post #101

This kind of thing shouldn’t even be a REST call. Use JSON RPC.

Why is that better?

First of all “/toggle” is not a proper REST endpoint. In fact, that is exactly what an RPC endpoint might look like. I can’t believe so many “developers” miss this.

With JSON RPC, he would POST a JSON object to a /toggle endpoint which runs a procedure to open or close his garage door.

If you want to be cute and conform to REST as much as possible, you would have to treat your garage door like a resource, and then use PUT to send the entire new state of the garage door to your API or PATCH to send the instructions for how to change the existing state (or use the +json media type for patch if you want to be lazy and just send a JSON object with updated key values). Your URL would probably be in the form of “/garage-doors/garage-door-id”.

Except, his garage door is probably NOT a resource and has no ID or even a serialized representation of it’s physical state. It’s just a physical door. And it should be driven remote procedures.

Maybe you don’t need any of this. Maybe you are happy with just using GET and pushing everything into REST and basically doing the wrong things. But that’s how you end up with the problems in the article, by not respecting standards, by choosing to be close enough to correct instead of technically correct. And frankly, if there’s any people who should strive for technical precision it should be engineers.

I personally would not hire a single software engineer who chose to approach this problem in the RESTful way without clear and deliberate reasoning for doing so.

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

#195

Post by Kihashi »

wpearse wrote: post #55
speps wrote: post #43

Earlier quoted context omitted.

EDIT: it's actually his address, I thought it was just a coincidence but you can the house on Street View... I removed the actual name as doxxing isn't great, sorry.

Thanks. Not the address with the WiFi garage thankfully. I was actually thinking "better not commit that" ... before, y'know, I committed it :/

It's possible to remove that from the history of your repo, although it breaks any forks.

https://rtyley.github.io/bfg-repo-cleaner/

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

#196

Post by criddell »

olavk wrote: post #178
criddell wrote: post #156

Earlier quoted context omitted.

The problem I have with that explanation is that it seems to assume the existence of a universal client. How many clients are examining responses and using that to build up a UI for actions with no anticipation of what those actions might be?

The universal client is a human who is trying to figure out how to implement a client against the API.

That doesn't make sense to me either. Why would you bloat all your responses with that information rather than documenting it out of channel?

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

#197

Post by emddudley »

PotionSeller wrote: post #163

>idempotent what does this mean

It's an important term in computer science. There is a good explanation on StackOverflow which I found by searching for "define: idempotent":

https://stackoverflow.com/a/1077421/111327

> In computing, an idempotent operation is one that has no additional effect if it is called more than once with the same input parameters. For example, removing an item from a set can be considered an idempotent operation on the set.

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

#198

Post by criddell »

JimDabell wrote: post #173
criddell wrote: post #156

Earlier quoted context omitted.

The problem I have with that explanation is that it seems to assume the existence of a universal client. How many clients are examining responses and using that to build up a UI for actions with no anticipation of what those actions might be?

I don't see why you jumped to that conclusion. What about that JSON requires a universal client? It seems trivial to implement a personal "Garage Automation Client" based on that JSON that doesn't have to deal with anything else.

I might have this 100% backwards, but I've always thought the application state part of HATEOAS is entirely in the client. Does the server know anything about application state other than maybe implicitly through resource state?

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

#199

Post by Ajedi32 »

zzbzq wrote: post #150

The real problem here, as usual, is web browsers, the worst class of software ever written. We constantly come across these CSRF-style bugs that are only made possible by how stupid the browser and HTTP are, but instead of blaming the culprit and trying to deal with the source, we blame ourselves for not being accommodating enough. Fool me once, shame on me, fool me 5,000 times, shame on me. Oh, and occasionally inve…

CORS is to _allow_ cross-origin requests, not to restrict them. Most such requests are restricted by default.

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

#200

Post by criddell »

mistermann wrote: post #164
criddell wrote: post #149

Earlier quoted context omitted.

> A single step, a button push, to confirm an unsubscription is fine. No, it really isn't. Lots of mailing lists operate exactly as the person you replied to mentioned where after unsubscribing you are given a chance to undo that action. That's a far more respectful way to operate.

What definition of fine are you using?

I don't want to be presented with a confirmation box every time I change something. Nobody reads them - they just click the button that will make it go away.
Post reply on HN