3 ms·
> No, this is a terrible response. As an aside, this kind of hyperbole really gets under my skin. It wasn't a terrible response. That statement is already tech
by bkanber 6y ago
> No, this is a terrible response.
As an aside, this kind of hyperbole really gets under my skin. It wasn't a terrible response. That statement is already technically correct: GET is idempotent, and the definition of idempotency is that it is harmless to repeat.
Your gripe is that OP didn't mention that GET is not only idempotent but must also be "safe"; i.e. that it should not alter the resource. OP got it 50% correct.
Does that omission make his comment a "terrible response"? No -- just incomplete.
- thaumasiotes 6y agoYes, it was a terrible response. Here are some examples of idempotent requests: - Change the email address registered to my account from owner@gmail.com to new_owner@136.com . - Instead of sending my direct deposit to account XXXX XXXX at Bank of America, from now on, send it to account YYYY YYYY at Wells Fargo. - Delete my account. - Drop the database. None of these have any business being available to GET requests. Objecting to a misconfigured endpoint on the grounds that the functionality it implements is not idempotent implies that the lack of idempotence is what was wrong. That's a bad thing to do - anyone who takes your lesson to heart is still going to screw themselves over, because you gave them terrible advice. They may do it more than they otherwise would have, because you gave them advice that directly endorses really bad ideas. Idempotence or the lack thereof is beside the point. Messing up on endpoint idempotence means you might hurt the feelings of a document. Messing up on endpoint safety means you might lose all your data as soon as anyone else links to your homepage. Or worse.