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

261–270 of 313 posts

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

#261

Post by mistermann »

criddell wrote: post #200
mistermann wrote: post #164

Earlier quoted context omitted.

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.

> I don't want to be presented with a confirmation box every time I change something.

That's much broader scope than what's being discussed here.

> Nobody reads them - they just click the button that will make it go away.

That statement is false. Many people read and care about confirmations.

What you're talking about is very specific personal preferences, not what is generally considered "fine".

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

#262

Post by dragonwriter »

NewEntryHN wrote: post #222

GET requests aren't supposed to be idempotent. They're not supposed to change state in a first place.

> GET requests aren't supposed to be idempotent.

RFC 7231 disagrees.

> They're not supposed to change state in a first place.

Well, yeah, GET is supposed to be safe, but all safe methods are also idempotent.

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

#263

Post by olavk »

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…

I don't really have anything against JSON RPC but it is just a standard for encoding a method name with dynamically typed parameters. You can say "close the door" in JSON RPC, or you can just post the string "close the door" to an URL. It doesn't make the service more robust or reliable to use an extra layer of wrappers.

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

#264

Post by dragonwriter »

phamilton wrote: post #13
guelo wrote: post #6

Is idempotency part of HTTP or just part of loose REST conventions?

> loose REST conventions REST is HTTP. "loose REST conventions" is when someone chose to ignore big chunks of the HTTP spec. In other words, you can build whatever you want (like SOAP) on top of HTTP and ignore the spec that describes content negotiation, HTTP methods, Caching policies, etc. It's still technically HTTP. But if you were to read the HTTP spec and follow it to a tee, you'd build a REST application.

> REST is HTTP.

That's actually backwards; HTTP is the motivating example of REST (that is, REST was developed from observed properties which HTTP/1.0 loosely exhibited and was consciously applied in design of HTTP/1.1.)

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

#265

Post by dragonwriter »

criddell wrote: post #96
bushin wrote: post #36

Earlier quoted context omitted.

> you'd build a REST application Nah, nerds would come out of the woodwork to inform you that what you've built is not a real REST.

Yeah - there's always a HATEOAS comment somewhere and I've never really managed to figure out what that means beyond using URI's rather than a database IDs + some documented endpoint path to point to other resources.

> there's always a HATEOAS comment somewhere and I've never really managed to figure out what that means beyond using URI's rather than a database IDs

You know how browsers use URLs to find content and Content-Type to decide what to do with it, and links ib URLs in content (so as anchor tags in HTML) to find related content: that's HATEOAS in the original REST API.

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

#267

Post by downer68 »

fenwick67 wrote: post #258
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

So what?

If I never intended for the GET to be GOT, then the browser is just as much at fault for such unintended consequences.

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

#268

Post by jholman »

CapacitorSet wrote: post #260
jholman wrote: post #82

Earlier quoted context omitted.

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)).

Yes, and nullipotency requires x = f(x) = f(f(x)), and four of the methods defined in RFC7231 are expected to be nullipotent, otherwise known as "safe". The point of mentioning that is to highlight the relationship between idempotence and nullipotence.

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

#269

Post by saalweachter »

greglindahl wrote: post #244
DCoder wrote: post #83

Many years ago, I was asked to look at why all the content had vanished from a site (not built by me). After digging in a bit, I found that: 1) the original developer's idea of handling an unauthorized /admin request was just to set a redirect header and continue processing the current request . 2) the /admin page had a grid of all the content on the site, with handy 'Delete' links that ran over GET without confirmat…

Was it blekko? We had a website owner email us about that issue when blekko's ScoutJet crawler was new... although I don't recall the bit about ignored redirect headers.

I'm pretty sure everyone with a crawler has hit this sort of problem before. The first startup I was at did with someone's wiki that had "delete" links everywhere with no auth.

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

#270

Post by jholman »

jiveturkey wrote: post #227
Ajedi32 wrote: post #206

Earlier quoted context omitted.

It's possible to be idempotent without being side-effect free. If you PUT some record, for example, then that operation _will_ have side effects (modifying the record). If you then PUT that same data again, the result will be the same (it's idempotent).

that’s not a side effect. in common usage, a side effect is an extra action, not the desired action itself. if you PUT some record, and some other record or state changes, that’s a side effect.

I don't disagree with common usage, but common usage is not what's being discussed here.

It is a side effect in programming usage (not just HTTP).

Something is side-effect-free if and only if the only result of it running is that you get an answer. If you ignore the answer, then you cannot tell you ran the function/method/call/whatever. PUT is not side-effect-free.

That said, side-effect-free-ness is an incomplete paraphrasing of the HTTP spec (RFC7231); you'll notice that the only mentions of the phrase "side effect" are giving examples of legal side effects.

Post reply on HN