Had a job interview recently that went well besides one little disagreement... and it has made me question my sanity. Tell me if I'm wrong.

They asked the difference between a GET and POST request.

Wow, that's an easy one, they're giving me a break, I thought to myself.

I said "GET is used to retrieve data from a server, whereas POST is used to add data to a server, via it's body, which a GET lacks" or something like that.

They were like "ya mostly, but GET can be used to enter data into the server too. We were just looking for the body thing."

And I'm like.... yeah, you could do that, but that's not what it's meant for.

They mention stuff about query parameters and I hold steady that GET and POST are different because GET has a specific purpose. Otherwise, we wouldn't need the "method" part of an HTTP request at all. We could just either include a body or not include a body.

I ended it with "Well, POST implies that you are adding data to a server, and GET implies you are querying data from the server. When I'm reading documentation, that's how I quickly determine what an endpoint does."

My confidence was a little shaken at this point. Crazy what two people with (I assume at least) 10+ years of experience telling you you're wrong will do to your confidence.

  • 32
    To quote the HTTP 1.1 spec: "The GET method means retrieve whatever information is identified by the Request-URI." In other words, it is incorrect to use a GET to upload data to the server.

    POST, on the other hand, "is used to request that the origin server accept the entity enclosed." So I'd say your answer was spot on.

    Source: https://w3.org/Protocols/rfc2616/...
  • 14
    @SZenC I'm surprised I argued at all. These guys were twice my age and one of them oversaw over 100 developers. They're (afaik) heavily focused on web services, too, so eventually I just let them have it. What's a fresh-outta-college guy supposed to do against a force like that?

    Oh well. If I get the job maybe I'll mention it to them ;)
  • 9
    I agree with the way you're describing it, and good for sticking to your guns.

    It says so on another reputed source: https://developer.mozilla.org/en-US...

    "Requests using GET should only retrieve data."

    A GET might change data in the server, like let's say this server remembers your filters for some table, yeah, you could say it changes data in the server if you're an autistic pain in the ass.

    But it's not or shouldn't, strictly speaking.
  • 2
    All of that are “conventions” The only difference is presence of BODY or not.

    Just as POST is often used to retrieve data, GET can be used to store data.

    Yes, on paper you are right. In reality no one cares. Just follow the doc
  • 10
    @NoToJavaScript Imagine reading through Twitter API looking for the new tweet endpoint. You filter by POST because fucking obviously it's a POST. You search for 15 minutes and can't find it. You search for all http methods and find the new tweet endpoint is actually a GET because someone had the same shitty attitude as you.

    Time and frustration wasted because someone thought that "in reality, nobody cares".

    Not a real example btw.
  • 8
    One trap where it becomes important is when mapping them to HTML. GET is the consequence of an anchor, POST usually a button.

    Now if some asshole abuses an anchor e.g. for logout because he wants it to look like the next and prev links beneath it, and he's a lazy asshole so that he doesn't use a button and CSS styles to make them look alike, that can result in interesting bugs if a browser uses aggressive link prefetching. Which the browser may do because GETting a link is not supposed to change server side state.
  • 26
    I don't GET the people mentioned in this POST. There's no OPTION to PATCH my bad joke away.
  • 6
    @nitwhiz GET outta hereeeee
  • 1
    Why would you filter by POST ?
    I would just enter “create tweet” or “add tweet” in the search.
    Oh even google it. I’m looking for a specific API (create tweet), I don’t care how they built it, as long as it is documented, and I can use documentation to call whatever they want.

    So you are lost, if a developer didn’t respect your vision of APIs.

    APIs world is a shit show. Read the doc, don’t EVER assume anything.

    Oh guess what ? it is literally the first google link

  • 4
    @NoToJavaScript it's first link because it's Twitter. Most APIs are not so lucky.
  • 1
    @AlgoRythm Yes, you are right.
    Then use ctrl+f on the page. Most of them have search.
    My point is : You can’t assume anything. Maybe dev was drunk while he coded all API calls with “PATCH” verb. Maybe for some reason (maybe technical on heir side), putting ALL APIs in POST is easier and changes nothing for client.

    Maybe another BS (or not) reason.

    And from client perspective : I don’t care which VERB server wants, it changes nothing in my code and it doesn’t make it harder or longer to develop / maintain.

    Special thanks for companies who provide some kind of tool to generate all APIs calls, or a simple library with no logic, but all endpoints defined
  • 5
    @nitwhiz use your HEAD
  • 2
    @asgs He already said it is not an OPTION :\
  • 5
    @NoToJavaScript in practice I would agree most of the time, but here we're talking interview questions. I would much prefer the candidate who shows a clear understanding of the theory and fundamentals over one who thinks the difference is just the presence of absence of a body.
  • 1
    You can send a GET with a body though. (At least, I tried it with a certain API, because their docs described putting the auth token in the URL even on a POST, and it worked, although I eventually implemented it more conventionally.) The only fundamental difference is the word, the rest is implementation.
  • 3
    I've once built a very proper REST API with GET/POST/PUT/DELETE....

    I was asked later, why I did that, they've never seen an API using this before, everyone would do it with just GET...

    So... you're not alone, pal
  • 0
    @d4ng3r0u5 Yeah, but wouldn't that be an incorrect implementation for the HTTP specification?

    Also I noticed many people believe that Get calls shouldn't at all edit any state, which is wrong. Get calls are almost always logged In the server side. Almost all publicly accessible services have quotas on Get calls.
    Also just imagine a FIFO workflow, it would literally delete entries on GET
    GET is GET
  • 4
    @HitWRight logging has nothing to do with your data, so all's fine...
  • 2
    I've become immune about giving a shit what experts think.

    You should too.

    If it makes sense, it makes sense.

    If it doesn't, tell them they're wrong..and stupid, and more importantly why.

    Maybe leave off the stupid part.

    Usually though, people with lots of experience know when to bend or break the rules, whats true in theory versus whats *practical*.

    Just take it with a grain of salt.
  • 0
    I would run away from them as fast as I could. Could you imagine what it would be like trying to maintain code written by them?
  • 1
    I know I'm late but you're entirely correct here. I would have seriously questioned working for someone who argued with me about GET somehow being used to mutate data.

    Good on you.
Add Comment