HTTP (Hypertext Transfer Protocol) is created to provide communication between clients and the server. It works as a request and answer.
There are two basic HTTP methods: GET and POST.
The GET method of HTTP requests data from a specified source. GET requests can be cached and remain in the browser history. It can also be bookmarked.
It should never be used while working on sensitive data. GET requests have length restrictions, and they should be used only to get data.
The code will look like this:
<html> <head> <title>Title of the document</title> </head> <body> <form action="/form/submit" method="get"> First name: <input type="text" name="username" placeholder="Your name"> <br/> <br/> <input type="submit" value="Submit"> </form> </body> </html>
The POST method submits data to be processed to a specified source. As opposed to the GET method, POST requests are never cached and do not stay in the browser history, and we cannot bookmark them. Moreover, POST requests have no data length restrictions.
The code will look like this:
<html> <head> <title>Title of the document</title> </head> <body> <form action="/form/submit" method="post"> First name: <input type="text" name="username" placeholder="Your name"> <br/><br/> <input type="submit" value="Submit"> </form> </body> </html>
Comparison of GET and POST Methods¶
|Back button/Reload||Harmless||It means that the data will be resubmitted. The browser must warn that the data will be re-submitted in this case.|
|Can be Bookmarked||Yes||No|
|Can be cached||Yes||No|
|Encoding Type||application/x-www-form-urlencoded||application/x-www-form-urlencoded or multipart/form-data|
|History||Remains in browser history.||Doesn't remain in browser history.|
|Data Length Restrictions||While sending data, GET method adds the data to the URL. The URL length is limited (maximum URL length is 2048 characters).||Doesn't have restrictions.|
|Data Type Restriction||Only ASCII characters allowed.||Doesn't have restrictions. Binary data is also allowed.|
|Security||It is less secured than POST as the data sent is a part of the URL.||POST is a little safer than GET as it is not remaining in browser history or web server logs.|
|Visibility||Data is visible to everyone in the URL.||Doesn't show data in the URL.|
Other HTTP Request Methods¶
Beside GET and POST methods, there are some other methods. See them below:
|HEAD||It is the same with the GET method, but it returns only HTTP readers, not document body.|
|OPTIONS||It returns HTTP methods that are supported by the server.|
|CONNECT||It converts the request connection to a transparent TCP/IP tunnel.|
The PUT method is mostly used for **update** abilities. In other words, with this method, we put a popular resource URL with the request body, which contains the representation of the original resource that has been recently updated. This method can also be used for generating a resource when the resource ID chooses the client, not the server.
Take into account that PUT isn’t considered as a safe method, because even if it creates or changes state on the server, it is idempotent. This means that if you create or modify the resource with this method and then make the same call for the second time, the resource will still be there with the same state as it did with the first one.
The example below requests the server to save the given entity-body in method.py at the root of the server:
PUT /method.py HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT) Host: www.w3docs.com Accept-Language: en-us Connection: Keep-Alive Content-type: text/html Content-Length: 160
After storing the given entity-bode in the file, the server will send the following response:
HTTP/1.1 201 Created Date: Tue, 13 Dec 2019 14:53:57 GMT Server: Apache/2.2.14 (Win32) Content-type: text/html Content-length: 40 Connection: Closed
The PATCH method is mostly used for **modify** abilities. It doesn’t need the whole resource. It only needs to contain the changes to the resource. This method is neither idempotent nor safe. Collisions between two PATCH requests can be very dangerous, as some patch formats need an operation from a popular base-point; otherwise, the resource will be corrupted.
As you can guess, this method is used to **delete** a resource that is identified by a URL. This method is idempotent, too. In the case of deleting a resource, it will be removed. And if you call for DELETE for multiple times, the result will be the same - the resource will be removed.
The example below requests the server to delete the method.py file, at the root of the server:
DELETE /method.ry HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT) Host: www.w3docs.com Accept-Language: en-us Connection: Keep-Alive
After deleting the file, the server will send the following response:
HTTP/1.1 200 OK Date: Tue, 13 Dec 2019 14:53:57 GMT Server: Apache/2.2.14 (Win32) Content-type: text/html Content-length: 20 Connection: Closed