14

It seems that sticking to POST is the way to go because it results in clean looking URLs. GET seems to create long confusing URLs. POST is also better in terms of security. Good for protecting passwords in forms. In fact I hear that many developers only use POST for forms. I have also heard that many developers never really use GET at all.

So why and in what situation would one use GET if POST has these 2 advantages?

What benefit does GET have over POST?

  • Duplicate of [When do you use POST and when do you use GET?](http://stackoverflow.com/questions/46585/when-do-you-use-post-and-when-do-you-use-get) – BalusC Nov 19 '10 at 16:05
  • When you want to share a YouTube video with your friends, you will thank to the GET method. – ghchoi Aug 13 '19 at 04:33

4 Answers4

7

you are correct, however it can be better to use gets for search pages and such. Places where you WANT the URL's to be obvious and discoverable. If you look at Google's (or any search page), it puts a www.google.com/?q=my+search at the end so people could link directly to the search.

You actually use GET much more than you think. Simply returning the web page is a GET request. There are also POST, PUT, DELETE, HEAD, OPTIONS and these are all used in RESTful programming interfaces.

GET vs. POST has no implications on security, they are both insecure unless you use HTTP/SSL.

Chris Kooken
  • 32,730
  • 15
  • 85
  • 123
  • I don't fully agree with the statement that GET vs POST has no implications on security. You might be right considering transport layer. However lots of webservers trace URLs and therefore GET parameters may end up in logs and so on. – Dominik Jul 12 '21 at 15:48
3

Check the manual, I'm surprised that nobody has pointed out that GET and POST are semantically different and intended for quite different purposes.

While it may appear in a lot of cases that there is no functional difference between the 2 approaches, until you've tested every browser, proxy and server combination you won't be able to rely on that being a consistent in every case. e.g. mobile devices / proxies often cache aggressivley even where they are requested not to (but I've never come across one which incorrectly caches a POST response).

The protocol does not allow for anything other than simple, scalar datatypes as parameters in a GET - e.g. you can only send a file using POST or PUT.

There are also implementation constraints - last time I checked, the size of a URL was limited to around 2k in MSIE.

Finally, as you've noted, there's the issue of data visibility - you may not want to allow users to bookmark a URL containing their credit card number / password.

POST is the way to go because it results in clean looking URLs

That rather defeats the purpose of what a URL is all about. Read RFC 1630 - The Need For a Universal Syntax.

Brian Webster
  • 30,033
  • 48
  • 152
  • 225
symcbean
  • 47,736
  • 6
  • 59
  • 94
2

Sometimes you want your web application to be discoverable as in users can just about guess what a URL should be for a certain operation. It gives a nicer user experience and for this you would use GET and base your URLs on some sort of RESTful specification like http://microformats.org/wiki/rest/urls

Adam
  • 619
  • 1
  • 4
  • 19
-2

If by 'web application' you mean 'website', as a developer you don't really have any choice. It's not you as a developer that makes the GET or POST requests, it's your user. They make the requests via their web browser.

When you request a web page by typing its URL into the address bar of the browser (or clicking a link, etc), the browser issues a GET request.

When you submit a web page using a button, you make a POST request.

In a GET request, additional data is sent in the query string. For example, the URL www.mysite.com?user=david&password=fish sends the two bits of data 'user' and 'password'.

In a POST request, the values in the form's controls (e.g. text boxes etc) are sent. This isn't visible in the address bar, but it's completely visible to anyone viewing your web traffic.

Both GET and POST are completely insecure unless SSL is used (e.g. web addresses beginning https).

David
  • 15,750
  • 22
  • 90
  • 150
  • 2
    Clicking a button can either do a GET or a POST, it depends on the method set for the form. A form can submit its control values in the query string of a GET request. This may or may not be desirable, depending on what you're doing with it. – Nate C-K Sep 06 '11 at 22:10
  • This is not necessarily true. The developer can make requests after the page has already been loaded by the browser via ajax. These requests are still executed client-side, but can be programtically executed by the developer in javascript. – Nick Painter Apr 21 '17 at 20:20