Live data from Hacker News

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

twitter.com

241–250 of 313 posts

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

#241
Primary effect - An effect on the input arguments, who's effect is captured in the output.

Side effect - An effect on state that was not passed in as input arguments, who's effect may or may not be captured on the output.

Side effect free - Also known as pure, means the function only has a primary effect. Thus it only effects the input in a way that the output captures.

Idempotent - Applying a function to itself results in the same effects. Applies to both primary and side effects.

Where things get weird, is that there's also the following:

- An effect on implicit input state, which did not come from input arguments, who's effect is captured on the output. This would be like a HTTP GET. Or any query on a DB where the DB is an implicit input.

- An effect who's effect is captured on implicit output state, either by having its effect captured on an input (like a modification to a pointed object), or captured on output not returned by the function (like print to screen). This would be like a HTTP POST.

And now if you look at all these, there's an easy permutations of them. So you can build a table like so:

  Input | Output | Idempotent
  Arguments | Return Value | Yes
  Arguments | Return Value | No
  Arguments | Outside State | Yes
  Arguments | Outside State | No
  Arguments | Arguments | Yes
  Arguments | Arguments | No
  Outside State | Return Value | Yes
  Outside State | Return Value | No
  Outside State | Arguments | Yes
  Outside State | Arguments | No
  Outside State | Outside State | Yes
  Outside State | Outside State | No
All these combinations are possible. That's why it can be really tricky.

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

#242

Earlier quoted context omitted.

So I'm actually really interested in this conversation -- I think it's a good one that everyone has that needs to just get resolved. I think deciding where to follow and how much to follow REST/HATEOAS is exactly what engineering teams should decide. There are escape hatches (POST can do just about anything) and lots of ways to do things but REST-ful (not pure necessarily pure REST) and HATEOAS-y (usually comes up in…

JSON-LD is a significant cognitive leap to reason about [1], and its descriptive power goes beyond what you could do with XML. A JSON-LD document is effectively an RDF document coupled with a JSON document, in a seemingly human-friendly form, although lots of people will recognize the letters but have no clue what they're reading. For that matter, link relations too are a cognitive leap, and no one writes 'smart REST…

I'm not sure it's possible for JSON-LD to go beyond the descriptive power of XML, because XML is so general, flexible and powerful (and you could cretainly represent an RDF document in XML) -- the big upgrade there IMO is that it stays in relatively human-readable form (though depending on the human, so does XML).

Ditto on the huge disappointment with the cobbled together SDKs when HATEOAS/JSON-LD-fluent applications represent a more robust future that could have been the current timeline.

Also, it's a shame that hyper schema couldn't reconcile with JSON-LD. JSON-LD is the one I'm leaning towards using at the moment, because of it's early consideration of things like multiple languages.

It's reassuring (?) to see the mention of the RAML/Swagger situation being a mess from someone else. I actually liked RAML more than the Swagger specification, but Mule (https://en.wikipedia.org/wiki/Mule_(software)) left a bad taste in my mouth once upon a time, when a team I was on was deciding how best to create an ESB. I choose to go with "OpenAPI" (AKA Swagger 3.0) for my projects going forward not for that single personal reason but rather due to the sheer amount of people that have gotten behind Swagger -- they seem to have won the mindshare battle, if not the war.

I have picked a lot of things I thought were cleaner/technologically superior/whatever that lost the mindshare war in my lifetime, I'm trying to cut down.

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

#244
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.

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

#245

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

> 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 the developer before they write their code. But then version 2 of the API may remove the close function and expand open to accept a value between 0 and 1. The client is going to need to be updated and the action list will again be useful for an afternoon.

> Can you see the parallels with how HTML forms work?

Okay - now that's a fantastic question that has me reconsidering everything I said. I think what's special about HTML forms is that the browser is the universal client. I have to think about that more though.

I appreciate you trying to help me see the light here. This is something that has bothered me since I first started reading about REST.

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

#246
post #136

Earlier quoted context omitted.

'Side-effect free' means that doing it once, twice or n >= 3 times (with same parameters) yields the same result, i.e. what it returns doesn't depend on any remote state that is altered by the call itself . However, an idempotent HTTP call is certainly not a pure function which some people seem to be mixing up. Pure functions don't work with I/O. REST is bit more specific and explicitly requires GET to be nullipotent…

> Pure functions don't work with I/O. there is a comment above that argue this point in better details. https://news.ycombinator.com/item?id=16966046 Basically it depends on the many nuances you have on "pure", "functions" and "idempotent"

When discussing HTTP behaviours I think it’s easiest to stick to the definitions of these terms given in the HTTP standard. Anything else is fruitless bikeshedding.

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

#247

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.

70 lines of code is over-engineering? That's nothing.

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

#248

Earlier quoted context omitted.

So I'm actually really interested in this conversation -- I think it's a good one that everyone has that needs to just get resolved. I think deciding where to follow and how much to follow REST/HATEOAS is exactly what engineering teams should decide. There are escape hatches (POST can do just about anything) and lots of ways to do things but REST-ful (not pure necessarily pure REST) and HATEOAS-y (usually comes up in…

JSON-LD is a significant cognitive leap to reason about [1], and its descriptive power goes beyond what you could do with XML. A JSON-LD document is effectively an RDF document coupled with a JSON document, in a seemingly human-friendly form, although lots of people will recognize the letters but have no clue what they're reading. For that matter, link relations too are a cognitive leap, and no one writes 'smart REST…

HAL is personlly my current favourite, it seems to add the minimal overhead on top of JSON whilst adding in links.

> JSON-LD is a significant cognitive leap to reason about

I fully agree. JSON-LD requires first some kind of idea about RDFa which I didn't even know was a thing until reading up on JSON-LD.

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

#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?

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

#250
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…

Actual public Certificate Authorities have done this too. You request a cert, it's authorized everything seems fine. Except, huh, the guy who was supposed to authorize is off sick today, how did that work? The email to the authorizer should just be sat in his INBOX until he gets back. Oh - the company's "Malware protection" system automatically dereferenced the "Do you want to issue this certificate?" link from the e…

Any chance you could provide articles on these grey hat activities? Sounds interesting
Post reply on HN