6 ms·
An interviewer once asked me what the difference between GET and POST were. My answer was along the lines of "well technically just four letters in the header b
by kevmo314 5y ago
An interviewer once asked me what the difference between GET and POST were. My answer was along the lines of "well technically just four letters in the header but they're used differently" and the interviewer was absolutely adamant that I was wrong and that there was some fundamental difference between GET and POST requests to the point that I tried numerous times to steer it back towards how they're used.
Eventually I gave up and just ended the interview.
- freedomben 5y agoI hate that. For some reason being the interviewer fills people with an unfounded confidence in their own knowledge. Some act like they're infallible in interviews. The result is that as a candidate you have to avoid harming their egos but at the same time don't contradict them. It can be like walking on egg shells. Last time I interviewed I pushed back but in a "are you sure? can we look it up?" kind of way and that seemed most palatable to them.
- thaumasiotes 5y agoThe name of the request is the only difference from the perspective of HTTP. But it's definitely worth mentioning that POST requests trigger a bunch of browser safety features that aren't triggered by GETs.
- stickfigure 5y agoHTTP doesn't assume the existence of a web browser...
- wanderer_ 5y agoTrue, but your garden-variety command-line utility might not be able to send a POST (like wget, but apparently curl can). Both of these concerns are valid and need to be taken together. GET can be run just like a normal URL and thus is more versatile, but as you probably understand, less secure.
- abhishekjha 5y ago>POST requests trigger a bunch of browser safety features that aren't triggered by GETs. Where do I read about these features getting triggered?
- deleted 5y ago[deleted]
- zestyping 5y agoGET is supposed to be idempotent, and shouldn't have irreversible side-effects. Still a good idea, in my opinion. Browsers know they can repeat GET requests but shouldn't repeat POST requests without explicit confirmation. If I'm interviewing someone who claims to be familiar with HTTP, I expect them to know this. They might choose otherwise in specific situations for specific reasons, but they should know the convention.
- rmbyrro 5y agoHaving GET requests producing side-effects is not a good idea. Idempotent or not. Should avoid. GET requests should be used to retrieve information, they're supposed to be read-only. At most we could record like a counter or stats about the request, but not mutate resources internally.
- zestyping 5y agoYes, agreed. I was hedging because warming a cache could be technically considered a side-effect.
- rmbyrro 5y agoI'm not sure that's the case. The resource receiving the GET request isn't producing any side effects in reality. The caching server/service in front of it is. The underlying resource (behind the cache) doesn't (shouldn't?) even know about the cache itself. And the cache doesn't mutate any data points, just may store a version of it.
- rmbyrro 5y agoThere actually is difference between the two. From the RFC 2616 specs [1]: > GET: "means retrieve whatever information (in the form of an entity) is identified by the Request-URI" [2] > POST: "used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI" [3] [1]https://datatracker.ietf.org/doc/html/rfc2616/ https://datatracker.ietf.org/doc/html/rfc2616/ [2] https://datatracker.ietf.org/doc/html/rfc2616/#section-9.3 https://datatracker.ietf.org/doc/html/rfc2616/#section-9.3 [3] https://datatracker.ietf.org/doc/html/rfc2616/#section-9.5 https://datatracker.ietf.org/doc/html/rfc2616/#section-9.5