Re:I don’t have time for coding challenges
by johnfn on Friday September 11, 2020 @09:38PM
(#24449121)
I was definitely in the wrong about GET/POST. The company I had previously worked for simply didn't really care too much about getting the verbs right, so I didn't really fret about them. And the company I'm currently at (multiple thousands of employees, strong engineering culture if I dare say so myself) just does everything as a POST. So it really is somewhat cultural whether you care about GET/POST or not.
But, IMO, even if you don't know, it's the kind of thing you learn once in code review and then don't worry about again.
Re:I don’t have time for coding challenges
by cameronh90 on Friday September 11, 2020 @10:50PM
(#24449401)
For E2E encrypted APIs, one could well argue that worrying about HTTP verbs is just wasting time for no good reason. POST (consistently) lets you attach a body too.
Just using POST for everything is a pattern I've seen becoming more popular recently.
Re:I don’t have time for coding challenges
by chrisandchris on Saturday September 12, 2020 @05:35AM
(#24451157)
No we can get into an endless argument whether verbs are abused or not...
IMHO, GET (as of today) gas the issue that it does not support a body. If I‘m executing a search (an idempodent action), how can I nicely pass a JSON object configuring the search? I‘ll just use POST for that... So then we‘re at the point where the url does not work anymore because we have a POST /findEmployee; POST /findContract; ... instead of GET /employee and GET /contract.
Maybe I‘m wrong here, but it doesn‘t like nice in my eyes using POST in that way.
Re:I don’t have time for coding challenges
by ulucs on Saturday September 12, 2020 @07:19AM
(#24451619)
The JS API's I used to develop in used a mix of query strings (for exact matches) mixed with JSON (for more complicated queries) all in the url parameters
Re:I don’t have time for coding challenges
by andreareina on Saturday September 12, 2020 @04:23AM
(#24450848)
Google Places API puts the key in a query parameter. Still don't know how I feel about that.
Re:I don’t have time for coding challenges
by hysan on Friday September 11, 2020 @08:52PM
(#24448896)
Not the OP, but from my experience teaching web dev, one possible reason is nerves. I’ve seen some of the smartest students make that mistake on an assessment simply because they were under pressure. A simple conversation afterwards shows that they do understand the difference (as expected). In the moment though, sometimes you just have a brain fart.
Re:I don’t have time for coding challenges
by wool_gather on Saturday September 12, 2020 @01:08PM
(#24453832)
This really can't be understated. The difference between your how your brain works when you're under the clock and know you're being observed vs. the "natural" flow of a calm working environment is tremendous. Anyone of us who's conducting the interview must do some kind of double-checking of obvious mistakes to fairly account for the limitations of the process.
Re:I don’t have time for coding challenges
by bitten on Saturday September 12, 2020 @03:19AM
(#24450573)
Yep! I have been in similar situations where you make a mistake and you get out right rejected. Surely it's better to explain the mistake to me and then we can discuss it. This can also be a nice cultural check too, how well do I respond to my own mistakes? It's a shame most people don't follow your idea here.
OK, I'm honestly curious here. What was the request, and why did you make such a decision? Do you think it is the right approach in this case, or that it's an insignificant mistake that does not represent a person's understanding of HTTP protocol?
I remember hearing about at least one story where using GET instead of POST lead to disastrous consequences, as some robot crawled all over the "delete" links - but I have to admit, I can't imagine how it would happen without other significant design flaws happening as well (as "delete" links being public or robot being able to crawl under authenticated user's identity). This sounds like an error that can cause irrational irritation by the reviewer, but I can't imagine it being the sole reason to decide that the author can't code.