Why are HTTP requests called "get" and "post"?

Question

Why, when the specifications for HTTP requests were being made, were the names "get" and "post" chosen? How is whether I want parameters to be hidden or not at all relevant to whether I'm retrieving data from a server or submitting it?

EDIT: Let me reformulate. I know what a GET and POST request is. What I want to know is, why can't I make a request that submits data to a server, and whose parameters can be seen in the address bar?

Answer 1

Why, when the specifications for HTTP requests were being made, were the names "get" and "post" chosen?

GET came first - it was the only verb supported in the original HTTP protocol - we can only speculate why POST was chosen. Perhaps because it is evocative of putting something (the post body) into an envelope (the HTTP request) and putting it into a postbox (the HTTP server!)

How is whether I want parameters to be hidden or not at all relevant to whether I'm retrieving data from a server or submitting it?

It isn't about "hiding parameters", it's to draw a distinction between requests which have a side effect, and requests which do not.

See RFC2616 section 9.1 for the details, but in summary...

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe".

So, while you can make a GET request submit data, repeating that same request should not have any other side effect, otherwise what you're doing isn't really HTTP.

Why can't I make a request that submits data to a server, and whose parameters can be seen in the address bar?

You can use an address which has a query string (GET parameters) as the target for a POST request - perfectly legal.

Answer 2

When you're sending a GET request, you generally send little data to the server and get a lot back. It's the other way around with a POST request. That's why you usually don't want to see all that data.