Glad that a QUERY method will be provided instead, and I learnt my lesson about giving against-the-grain responses to interviewers.
Glad that a QUERY method will be provided instead, and I learnt my lesson about giving against-the-grain responses to interviewers.
Not passing judgement - you may have very well qualified your statement. But having dealt with the above issue some years back (as in being the person on the debugging run) I do sympathize with the unhappiness. :)
I've had a similar interview where I was interviewing and this came up, the interviewee didn't pass but it wasn't because they said GETs could have bodies. That was just one of the reasons, and they would've passed if that was the only "wrong" answer.
If they had explained that you could indeed have a body in a GET request, even if it went against the spec and you'd probably have to modify you existing body parser to comply, I would have accepted the answer as "correct". What matters is if you can explain your answer, not if you can answer yes or no questions.
In the end they didn't explain their reasoning and I just said that GETs can indeed have a body, but it goes against the spec, so it's gonna be hard unless "you own the entire stack", like a parallel comment said here. This way they have a base to explore more info later and improve for their next interview.
I've had plenty of intelligent answers that seemed weird to me before I followed up. Or "wrong" answers because I didn't explain the question well or there were different assumptions. Red flags shouldn't be red flags until you probe and give the candidate a chance to explain (or dig a deeper hole).
Ideally an api gateway should have managed the headers but ours didn't. Not at that time at least.
One thing I can think of: there some optimization that would cause performance degradation for 99% of GET requests.
These discussions sometimes go off the rail because it's a bunch of STEM folks critiquing the humanities, so I'll share a STEM example that gets the point across. A too-clever friend of mine got marks off in our Analysis course because he presented a constructive proof of a theorem on a test, and that was not the proof technique that the test was designed to interrogate.
Superficially his answer was "correct". But then, as his professor pointed out, on an even deeper level it really was incorrect, because our write-ups of proofs are really high-level descriptions of formal derivations, and the student was describing a proof a different axiomatic system than the one assumed by the question, so, to be totally correct, he would have had to embed the proof that his proof in constructive analysis mapped over into normal analysis. Which would have been quite a bit of work that the student, at the time, was unable to do (and probably no one could do in an exam setting).
But, again, the real point is that this part of the debate is pedantic because what my clever "friend" really didn't understand was WHY the question was being asked. The answer is supposed to demonstrate a certain piece of knowledge in a certain context; it's an exam answer in a closed curriculum, not a Treatise.
Besides, you are ALWAYS writing into a audience and context; if you want to write to a "pure" audience, you may do so, but consider saving it for Sunday morning prayers.
Which, since that friend isn't paid to write analysis proofs these days, were perhaps important lessons ;)
Careful with the attack surfaces that entails, though: https://blog.cloudflare.com/understanding-our-cache-and-the-...
Generally speaking there's nothing wrong with against-the-grain responses if they're well argued for, especially if you can compare them to the other, more common, options and make your solution sound the best. "Elastic search does this, and it might be easier to cache" don't sound like the best arguments to me.