I think it might help to re frame this a bit to not look at these as parameters, but take a step back.
Ultimately the purpose of the
GET request is to ask a server for the representation of a given URI. The fact that the URI has things that are ‘parameters’ or ‘variable’ is kind of irrelevant here.
The idea of the
GET request is, give me the thing at this URI. The fact that there are some mechanisms to dynamically build up these URIs is not important.
You can do the exact same thing with POST. Any URI that you can
GET, you could send a
POST request to. So these URI variables can also exist for
So on a high level, this is what the requests are for:
GET - Return the representation at the given URI PUT - Replace the representation at the given URI DELETE - Remove the resource at the given URI
Looking at these operations as something you do at the given URI it starts to make sense that
GET doesn’t have a request body. If the purpose of the request is simply ‘give me the thing at this uri’, there’s no real reason to also have a body.
Likewise, it doesn’t make that much sense for a
PUT request to respond with a body. The purpose of
PUT is to replace whatever is at the given URI with the request body. The caller only really needs to know if the operation succeeded or not, so a HTTP status code is enough.
DELETE neither the request or response body really makes sense. All you need to know is there is a URI, and you are calling the DELETE operation, which succeeds or fails.
So what about
POST is really a bit of a catch-all that is used for basically ‘anything else’. You’re not explicitly replacing, removing or retrieving a resource, but rather you are doing ‘some arbitrary operation’, like doing an RPC call or creating a new resource in a collection.
DELETE, the meaning of
POST is much more loose.
POST - Do an arbitrary operation at the given URI.
CLICK HERE to find out more related problems solutions.