This brings back memories. I once failed an interview because an interviewer asked me how a certain API could be implemented and I suggested that you could send a body with a GET request. My thinking at the time was that, even though unusual, Elasticsearch does this (2016: https://github.com/elastic/elasticsearch/issues/16024#issuec...) and it might be easier to cache than POST but I could tell that the interviewer wasn't happy with my reponse.
Glad that a QUERY method will be provided instead, and I learnt my lesson about giving against-the-grain responses to interviewers.
The QUERY method is definitely the way to go. GET with a body is iffy. If you owned the entire stack it might be doable. But once you don't have control of the many http proxies and firewalls that a GET with a body has to travel then it becomes a problem. I think the RFC does not explicitly define the behavior of GET with a body. So, proxies or firewalls can just drop the message and be completely HTTP compliant.
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. :)
Yeah, your point about needing to own the entire stack in this case makes perfect sense, and to be honest, I didn't qualify what I said well at all at the time. When I left the interview I had that sense of "damn, why did I say something so strange with no explanation of where I'd seen this or argument against it". There could have been a conversation about it, but my response just made the interviewer tick the 'no' box.
Yeah, that's on the interviewer for not asking follow up questions.
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).
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.
Sort of reminds me of how at one point, the Ruby HTTP client wouldn't let you send query parameters in a POST request. Somewhere out there there's an issue where someone reports that, and the maintainer is appalled that someone would even want to do so!
But those same proxies/firewalls probably won't understand QUERY either, right? And if they are updated to add support, why can't they be updated to add support for GET with request bodies?
Oh damn... I've seen this one too. As always this is doing REST api without understanding the nuances of http and its headers. The application service in this case wasn't setting the correct cache-control. A proxy some layers above happily cached it. Adding the cache-control didn't make a difference. The proxy had to be restarted (the cache was within its ttl so didn't get changed).
Ideally an api gateway should have managed the headers but ours didn't. Not at that time at least.
The same advice applies for university exams. (Note, particularly in essay based subjects.) Don't provide against the grain answers no matter how smart or well thought through. Your university professor wants to hear how clever he/she is and wants you to write opinions that agree with their point of view. It's the best way to get marks. Just copy the party line. I was told this by a very clever university professor. It still makes me smile lol
This is only kind of true. If you are asked "why is X true?" and you go on critique the epistemological basis for saying that something of type X could be true or not, you may be giving an in-depth and intelligent answer that is responsive to the prompt. But you are also not demonstrating the knowledge that the question was designed to probe; i.e., that you have learned and retained the particular arguments for the truth of X that were covered in class.
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 ;)
> I learnt my lesson about giving against-the-grain responses to interviewers.
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.
One issue, for me, is that as soon as you step out of the realm of GET and POST you start needing to content with proxy servers that are doing stupid things and misconfigured - you also bump into the issue that for some inconceivable reason HTML forms are still restricted to only supporting GET and POST methods. I've written GET requests with bodies and, while they're normally not that useful, if you've got a big chunk of serialized data in the request (i.e. some random blob of JSON with config settings) then they're a reasonable solution. QUERY is nice, but GET is known and, when talking about the web, old standards are a lot more trust worthy.
Glad that a QUERY method will be provided instead, and I learnt my lesson about giving against-the-grain responses to interviewers.