0
I read that the method GET is considered "safe" and the method POST is considered "unsafe". Shouldn’t it be the other way around? The method POST does not expose the data sent in the URL, so it should not be considered "safe"?
When should I use the method GET and the method POST?
It is not more advantageous to always use the POST since the GET has more limitations, such as the character limit?
3
I see many answers explaining when we should use the method GET and when using the method POST of the HTTP protocol and basically the answers are limited to explaining advantages and disadvantages of each method which culminates in the choice of the POST as the safest methods.
We usually use the method POST in the forms to communicate with the server, no matter if the action will have "side effects" or not. We simply do so apparently for no reason or for the first time POST is safer.
But is that true?
If you read the HTTP RFC, you will find that the method GET is described as "safe". Safe, in the context of HTTP, means that you should be able to do multiple GET’s for a web application and this shouldn’t cause side effects, like deleting a news item, it shouldn’t cause changes to the feature being requested, because the whole idea of the method GET is that you should simply receive a copy of the resource that is in that specific URL. You’re not doing anything special with the feature, you should be able to receive it anywhere and any time you wish.
However, reading the method description POST, you will find that it is an "unsafe" method. If you send a POST For a URL, you could definitely be changing something on the server and causing undesirable side effects. Or you may simply be creating a new feature, such as a blog post.
The obvious difference is that the POST can (and should) change the status of something on the server side, while a GET should never be able to do the same. Comparing to databases they use SQL, Gets would be like "selects" and Posts as "Inserts". Have you ever seen an "Insert" that returns a result table or a "select" that inserts data into the database?
But of course everything can get even worse. Imagine that you are the owner of a site that uses only POST on all your forms and one of these is a search form. Users will use it to search for products and add them to their shopping cart. Imagine that the user is interested in buying a particular product, but he is not sure of the name, so he simply type something and press "enter" on the keyboard (or send button)...
There it is!
A list of products appears. He clicks on the first one and discovers that it was not the intended one, so thinks the unsuspecting user: "I will press the back button and look for the product in the rest of the list...", and when he clicks on the button, the browser shows an interesting message:
The browser needs to send data to the server to perform this action. You are sure you want to do this?
As HTTP protocol defines, the method POST is not a "secure" method and the tools - usually browsers - should warn the user that something bad might happen if they try to send a POST by accident on a page. And that’s exactly what happens when trying to click the back button after a POST. In this example, the user wouldn’t be doing anything wrong, but imagine if instead of going back to a search page, he could be going back to the "add customer" form and a "go back" could very well cause the new customer to be recreated in the database, which would not be the intention of the user.
Worse, if you’re using POST in a search form, users will never be able to use the back button (the usability masters say it’s the most used thing in browsers) and they won’t be able to put that result page in their favorites either! Can you imagine anything worse than that? You are preventing people from expressing all their love for your site by posting links to them on del.icio.us!
The idea is simple, if you are not changing anything on the server, you should always use GET, Whatever. It doesn’t break the back or update button, lets the user add the requested pages to the bookmarks and won’t cause browsers to show scary messages to users.
If you are changing the state of something on the server, you should use the POST (and other HTTP methods that are defined as "insecure", such as PUT and DELETE), requests that use GET NEVER should change resources on the server (know that link you made that erases a record in the database? It was a bad idea!).
You may be wondering: "Then I should send the login data via GET, since I am not changing any resource on the server?"
I answer with another question: authentication/authorization does not change the status of the user within the application?
It is a free translation of http://blog.codevader.com/2008/11/02/why-learning-http-does-matter/ although 2008, very current.
Browser other questions tagged rest http post get
You are not signed in. Login or sign up in order to post.
May be useful.
– ptkato
I’ve heard otherwise: that
GETis insecure andPOSTis safe. Security also depends on who program, regardless of method.– Wallace Maxters
@Wallacemaxters isn’t what the spec says and I kind of agree. The POST is considered safe because it is used incorrectly, but I believe that whoever created the specification (which is where the answer is based) was not mistaken.
– Filipe Moraes
Possible duplicate of What are the HTTP request methods, and what is the difference between them?
– Bacco
@Bacco does not agree with the duplicate, although they are identical subjects, they are not treated in the same way. The answer is completely different from the question marked as duplicate, I even saw these questions before posting this.
– Filipe Moraes
I was in doubt of closing as duplicate of that, or this: When to use GET function and when to use POST function? - And there was more recent talk about it. Remember that nothing prevents you from posting something there that complements the existing answers.
– Bacco
@Bacco still not agreeing with you, here the question is why one is considered safe and the other insecure according to the specification, because what we have is the opposite. The question of when I should use each other was a part to complement the answer.
– Filipe Moraes
There’s another one that talks about it, just out of curiosity :) http://answall.com/a/106507/70 (I couldn’t resist not linking just because of idempotent) As a complement, this is legal, speaking of PUT and POST: http://answall.com/questions/92870/
– Bacco