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

221–230 of 313 posts

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

#221

Post by PuercoPop »

mbid wrote: post #78
StavrosK wrote: post #74

Earlier quoted context omitted.

I dispute your example. If you call f(2) and it always returns 4, it's idempotent and side-effect-free. If you call f() and it returns 4, then 8, etc, it is neither.

From wikipedia: "A unary operation f, that is, a map from some set S into itself, is called idempotent if, for all x in S, f(f(x)) = f(x)."

Instead of checking wikipedia for a general definition of idempotency, check the RFC for the definition that applies to HTTP

9.1.2 Idempotent Methods

   Methods can also have the property of "idempotence" in that (aside
   from error or expiration issues) the side-effects of N > 0 identical
   requests is the same as for a single request.

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

#223

Post by Drdrdrq »

jimktrains2 wrote: post #142
wpearse wrote: post #55

Earlier quoted context omitted.

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

git add -p It will let you approve each hunk in a file to commit or not. git commit -e -v Will force you to edit the commit message and in the editor show you the diff of the commit against HEAD.

Thank you! I use 'git add -p' all the time, but didn't know the trick with commit. I am a sucker for nice commits so I will check every commit's diff multiple times. When I don't, I usually end up including pieces of code which is not ready yet, which is meant for debugging,...

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

#224

Post by richardwhiuk »

swiley wrote: post #99
mbid wrote: post #78

Earlier quoted context omitted.

From wikipedia: "A unary operation f, that is, a map from some set S into itself, is called idempotent if, for all x in S, f(f(x)) = f(x)."

I think because in math you don’t ever have side effects you usually use composition where in programming you usually use a sequence. So to change that function in to how people would implement it means rearranging the internal stuff and then it probably wouldn’t be idempotent be either definition.

But not the reverse. If you are side effect free you must be idempotent.

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

#225

Post by wpietri »

Can_Not wrote: post #208
criddell wrote: post #192

Earlier quoted context omitted.

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.

I don't think it's slimy. They could provide a simple, complete unsubscribe button in addition to a list of subtopics to check/uncheck. Maybe I only want to unsubscribe from their blog, or I still want to receive feature update news but not their sales catalog.

As a person who ends up clicking a lot of unsubscribe links: I definitely see it as slimy.

I would rather companies just didn't subscribe me, so having to click an unsubscribe link is already a problem. The more confirmation they have, the more I take it as biased and manipulative.

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

#226

Post by micimize »

This comment thread has really put me in a good mood. These stories have so much pedagogical value: • The grammars we engineer have important semantic value • understanding and adhering to them is important, and hard • relying on others to adhere to them is dangerous, and hard to avoid • "experts" make mistakes in both areas constantly

I genuinely love seeing this kind of lively discussion, because these seemingly "trivial details" matter, a lot. The Three Mile Island accident was more or less caused by "message sent" being conflated with "state changed" at the UI level, directly leading to a nuclear meltdown. They basically had a system with the equivalent design of GET /open and /close that assumed success for both https://en.wikipedia.org/wiki/Three_Mile_Island_accident#Con...

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

#227

Post by jiveturkey »

Ajedi32 wrote: post #206
smaddox wrote: post #166

Earlier quoted context omitted.

But `GET(GET(x))` doesn't make sense, in general (and if it did, then you would not expect it to be idempotent), so clearly idempotency in this context is meant to mean side-effect free. They should probably just say side-effect free, though, to avoid the confusion.

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.

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

#228

Post by always_good »

AnIdiotOnTheNet wrote: post #121
a13n wrote: post #117

Earlier quoted context omitted.

1) Market disagrees with you strongly, hence hundreds of millions of people using it regularly. 2) He's just having fun, working on a side project that's useful to him, and learning. Nothing wrong with any of that. Why so negative?

1) Popularity is rarely an indicator of quality. 2) That doesn't mean it isn't over-engineering.

If actually being used by people isn't part of your criteria for a good medium, then I'm not sure it's very useful.

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

#229

Post by criddell »

JimDabell wrote: post #216
criddell wrote: post #198

Earlier quoted context omitted.

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?

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 hours I've been sleeping. So I'm going to Fitbit ahead of time knowing what I want to do.

If you were going to craft a client UI based entirely off the server responses, you are going to recreate the Gopher experience, and nobody wants that.

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

#230

Post by hashmush »

wwweston wrote: post #53

Perhaps we need a specific nomenclature for this sort of case: oddempotent! After all, you get the same state if you do it 3,5,7,9,etc times as if you do it once, right? ;)

That would be an involution!

https://en.wikipedia.org/wiki/Involution_(mathematics)

Post reply on HN