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

Well if that's the case then the interview process was not well put together.

Why is that?

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?

>why can't they be updated to add support for GET with request bodies?

One thing I can think of: there some optimization that would cause performance degradation for 99% of GET requests.

There is no standard they can all agree on.

I’ve worked with people who go further and won’t use GET requests at all (everything is POST) to avoid pathological caching cases with GET.

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.