3 ms·

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

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

lhnz 5y ago
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.
- cema 5y ago
  Well if that's the case then the interview process was not well put together.
  - ranguna 5y ago
    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.
- brianpan 5y ago
  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).
nicoburns 5y ago
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.
- gautamdivgi 5y ago
  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.
twic 5y ago
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!
shawnz 5y ago
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?
- Kinrany 5y ago
  There is no standard they can all agree on.
- nemothekid 5y ago
  >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.

lhnz 5y ago

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.

cema 5y ago
Well if that's the case then the interview process was not well put together.
- ranguna 5y ago
  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.
brianpan 5y ago
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).

nicoburns 5y ago

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.

gautamdivgi 5y ago
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.

twic 5y ago

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!

shawnz 5y ago

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?

Kinrany 5y ago
There is no standard they can all agree on.
nemothekid 5y ago
>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.