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

251–260 of 313 posts

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

#251

Post by always_good »

matte_black wrote: post #234
olavk wrote: post #232

Earlier quoted context omitted.

Yeah OK, so JSON RPC avoids this particular problem by simply not supporting GET. But that is kind of throwing the baby out with the bathwater, since GET is quite conventient when used appropriately.

Consider what would happen if he didn't want to merely "toggle" his door, but rather have it closed, definitively and once and for all. Could he do that with /toggle? Does he know the state of the door well enough to know if toggle is the right command? Can he even trust the state of the door being told to him? What if it's already closed and it opens instead? No. The only way is to send a message that directly says…

`POST /door` with `state=closed` excels at this too.

Still not seeing how JSON RPC itself is an improvement over the root solution but an unrelated impl detail.

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

#252

Post by always_good »

NoGravitas wrote: post #124
criddell wrote: post #112

Earlier quoted context omitted.

Do you really like having to confirm every action? For interfaces that you use all the time, it's nice to be able to eliminate extra steps.

If you're using it programatically (e.g., a script that's calling curl), it's absolutely no trouble to use POST. If you're using it from a browser, you can write it with a confirmation page for simple browsers, but also use just a little javascript in normal browsers to convert the GET to a POST and skip the confirmation page.

Also, if you have a confirmation page on GET, then it must be submitting to a POST endpoint that you could still call directly.

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

#253

Post by strictnein »

hardwaresofton wrote: post #16
onion2k wrote: post #12

Earlier quoted context omitted.

Exactly. A 'toggle' should really be implemented as a PATCH request, or maybe a PUT if there's no data other than the door state.

At the risk of being overly pedantic/piling on -- this is what bad REST-ful API design looks like in practice. When you talk to your teammates about the semantics of these verbs and someone just says "oh a GET is fine" and the team agrees but you don't and you can't say it so you don't become "that guy" it's time to find a new engineering org to be a part of. On the topic of PATCH, check out JSON merge patches (appli…

Hadn't seen that RFC before. We were doing almost exactly that on a large API project a year or so before that RFC was published. Backend guys hated it, front end guys loved it.

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

#254

Post by phamilton »

tzahola wrote: post #33
peteretep wrote: post #25

Earlier quoted context omitted.

> REST is HTTP This is untrue. I hate to quote from Wikipedia, but it sums it up quite nicely: "REST is not a standard in itself, but RESTful implementations make use of standards, such as HTTP, URI, JSON, and XML" More colloquially: REST is what happens when people mix up transport layers in their head.

HTTP is an implementation of REST.

This is more the point I was trying to make.

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

#255

Post by TheCapn »

slig wrote: post #114
AnIdiotOnTheNet wrote: post #110

Two thoughts: 1) Twitter is a terrible medium for anything, let alone posts longer than a sentence. 2) The level of over-engineering tech people readily engage in without a second thought is truly mind boggling.

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 otherwise it'd probably be an even larger monstrosity today

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

#256

Post by phamilton »

criddell wrote: post #229
JimDabell wrote: post #216

Earlier quoted context omitted.

The server tells the client about the state through the hypertext documents it sends it. The client then transitions to a new state by performing an action described in that document. Hence: Hypertext/Hypermedia as the engine of application state (HATEOAS). I'm still not grasping why you think the API above needs some kind of universal client though. You can implement a very simple client for that extremely quickly.…

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. For example, say we are writing a client to do something with Fitbit data. Step one wouldn't be to send a GET to the root to find out what actions are possible, would it? We might find out they have APIs for tracking vehicle mileage but I don't want that in my client - I just want to graph the hou…

> just that it's the only real reason I can think of for including all of that

Having done a fair bit of HATEOAS driven APIs, but one benefit of the above is that it allows you to change "/open" to "https://otherservice.com/open" if needed and applications will start hitting the correct endpoint. Sure you can solve that with redirects or a reverse proxy config entry, but in my limited experience it is quite convenient to specify that in the response.

One good example is something you've probably already done: Download URLs. Instead of having clients build "https://cdn.photoservice.com/photos/12341231/download" whenever they want to download a raw file, they instead hit "https://api.photoservice.com/photos/12341231" which has a "download_url" in the response. They then fetch the file from that url. In my experience that download_url is region specific, or it has query params that AB test different resolutions, or it's AB testing different CDNs, etc.

I hope that benefit is clear enough. Now think about how those same benefits can be applied to a wider range of API endpoints. That might seem like overkill to do everywhere, and probably is, but it certainly has benefits in the right situations.

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

#257

Post by scottmf »

downer68 wrote: post #249

This, kids, is why GET requests should be idempotent. Or, like, you know, how about a browser only sends a request when I'm actually fucking asking for something, and doesn't try to fetch everything I've ever thought about, with my every slightest accidental finger twitch against its touch screen? What happened to deterministic user interaction?

Darn kids and their prefetching, GET off my lawn!

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

#258

Post by fenwick67 »

downer68 wrote: post #249

This, kids, is why GET requests should be idempotent. Or, like, you know, how about a browser only sends a request when I'm actually fucking asking for something, and doesn't try to fetch everything I've ever thought about, with my every slightest accidental finger twitch against its touch screen? What happened to deterministic user interaction?

GET is meant to get, not set. Since 1.0.

https://www.w3.org/Protocols/HTTP/1.0/spec.html#GET

> The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI

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

#259

Post by dragonwriter »

onion2k wrote: post #12
groestl wrote: post #11

Idempotency might be necessary for GET calls, but it's not sufficient. Imagine he had two separate GET calls (opened/closed): the author would still have the same problem. Browsers assume GET to be safe (non-mutating), and safety implies idempotency.

Exactly. A 'toggle' should really be implemented as a PATCH request, or maybe a PUT if there's no data other than the door state.

A toggle would actually be a good use of POST, though PUTting the desired state would be better (PATCH works instead of PUT if you are changing some part of the state and not the whole state, but is unnecessary if the door state consists entirely of either “open” or ”closed”.)

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

#260

Post by CapacitorSet »

jholman wrote: post #82
laneb wrote: post #73

Earlier quoted context omitted.

The typical operation applied to sets of functions is composition, so idempotency of a function f is the condition that f(f(x)) = f(x) for all x in the domain of f. I don't think that applies meaningfully to GET.

It does apply to HTTP idempotency. `x` is the state of the server. `f` is the change to the state of the server that ensues when one makes such-and-such an HTTP call. So taking PUT as an example, `x` is the state before the PUT, `f(x)` is the state after one PUT, and `f(f(x))` is the state after that single PUT is sent twice. Of course in a RFC7231-compliant server, `f(x) = f(f(x))`. Taking GET (or any other nullipot…

Technically speaking, idempotency as defined by RFC7231 only requires f(x) = f(f(x)).
Post reply on HN