If you have done any kind of web development then you must have come across these two terms GET & POST. These terms are introduced with respect to the form tag. The explanation was like this:
“In the form tag, there is an attribute called method. There you can specify in which way you want to send data to the backend. There are two values present for this attribute which are GET & POST.”
GET: If you use this method then the data you have written in the form will be appended to the URL and will be sent. As the user inputs are clearly visible in the URL, this method is not secure and there is a limit to what you can send and how much you can send.
POST: If you use POST then the data will be sent in HTTP request body. It won’t be visible in the URL. There is no limit on how much data you can send. POST also supports the sending of any kind of data.
I have observed everywhere, this is very much how GET and POST are introduced to students. Although this much explanation is enough for one to use GET and POST in the context of forms, they do not give a clear understanding of these two methods.
Below is the explanation with an example. We will be using the PHP code for the examples. (We have used $_REQUEST to capture the data so that the same file can be used for both).
<?php echo "Hello ".$_REQUEST['name']."!!"; ?>
GET: Here is the code of GET form.
As expected the values of the parameters appeared in the URL. But if we use the chrome inspect tool to analyze a bit more we can see the values that are present under the section “Query String Parameters“.
POST: Here is the code for the POST form. If you notice, it is identical to our GET form except for the value to the method attribute.
The data is sent. But now if we inspect it using Chrome tools, the parameters are appearing under the section “Form Data“. GET and POST belong to a family called HTTP Methods (The name of the attribute method came from here). Some of the HTTP methods are GET, PUT, POST, DELETE, HEAD, PATCH, OPTIONS, TRACE etc.
They all serve multiple purposes for the HTTP protocol. We would be mainly focusing on the first four in this article.
CRUD Operations: If you are working with databases, then you must have come across these terms. In layman terms, I can explain CRUD as the basic functionality that must be provided to End Users through APIs to be able to properly utilize any Database Management System (In your web development context it will be the DBMS that you are using along with your server code, say MySql, Hibernate, etc). CRUD stands for CREATE, READ, UPDATE and DELETE. The four HTTP methods, As I mentioned earlier corresponds to one of these operations.
- CREATE: The SQL command will be used to create a record in the Database. The HTTP method corresponding to this operation is POST, as you will be “POSTING” values in the request body to be added in the DB).
INSERT INTO tablename VALUES (value1_for_column1, value2_for_column2, . . );
- READ: It is used to read a record that is already present in the DB. One can specifically ask for the records he/she wants to read using the WHERE clause. The SQL command will be:
SELECT * from WHERE columnX = valueX AND columnY > valueY . . . ;
The HTTP method corresponding to this operation is GET. Try to compare this with the URL generated after a GET request, i.e. the part after ‘?’ mark in the URL, with the expression after WHERE clause. They both are quite similar, aren’t they?
- UPDATE: This is used to update a record in DB. The corresponding HTTP method is PUT. In SQL we can achieve this by UPDATE statement.
- DELETE: It’s kind of speaks for itself. One wants to delete a record. The HTTP method and the SQL command both will be DELETE.
Now if you think about the outputs we had earlier, it makes much more sense. For GET the request body was empty and values were under Query String Parameter. Because the form fields were treated as a parameter to the query that is asked to the URL “localhost/target.php“.
In the POST method, the data entered in the form went with the request body. So it appeared under the section Form Data. It is being treated as some data that the user wants to send, rather than some parameters to a query.
GET and POST: Now let’s dial back a bit and think in terms of the designer of the HTTP protocol. We know that GET is designed to be used in cases where the user is requesting a list of records. The fields on which the user makes a search is usually very small and is text. So, for a GET request, there is no need to allow anything other than texts and anything more than 30kb. Rather if we keep is small then the processing delay will be lowered.
Now with these things in mind, try to think about some applications that you use daily where you think GET is being used. Yes! Search Engines. Now open a search engine try to search for something. Observe the URL that came up.
- Bing Search:
- Google Search:
Let’s think in terms of developers of HTTP again. Through POST a user will be creating new records that will need a large size of data to be passed. This much data can’t be passed through URL, so it’s better to send them as HTTP packets. Moreover, the record may contain some personal data so the POST method must be secure. Therefore, POST is used with forms that deal with user data (like google forms, when you are creating a new account on GfG).
Since now I have talked about creating an account you may be wondering, “What about login? There, one doesn’t create any new records! Then why GET is not used there?” Though one can simply throw away this question by saying as GET is not secure we don’t use it for login. But let us think about it in the context that we are discussing until now. While logging in, you are not actually requesting/searching for your record. Let’s think login in terms of searching. Then you are passing username and password and asking the system is there any account present having these credentials. That will be very wrong, Rather when we do login we request the system to allow us to interact with our data. In bank analogy, login will be asking the manager to provide us the key that will open our locker while searching will be asking whether person X is having a locker in this bank or not which again is very wrong and defeats the whole purpose of privacy. So, if you provide the correct signature then the manager will provide you the key that will open the locker. In web development, the server will provide you with sessionId.
Let’s wrap it up. While logging in, if the credentials are correct the backend will create a session for you and will provide a sessionID. Now using the sessionId you can search your data. So, POST is appropriate for this situation. And, once you are logged in, you can use GET requests to retrieve your data.
Conclusion: To summarize GET is used for reading/accessing some resources and POST is used to create it. I would suggest you not to restrict yourself thinking resource with respect to DBMS, rather think about it in a broader sense. The resource can be anything, starting from a row in the database to files like images or text or sometimes even complete HTML pages. If you want to read/search for a resource, then use GET and if you want to create/add/upload a resource, then use POST.