HTTP Request Method defines how data should be sent to the server. The two most used HTTP methods are: GET and POST.
The Hypertext Transfer Protocol (HTTP) is designed to enable communications between clients and servers. HTTP works as a request-response protocol between a client and server. A web browser may be the client, and an application on a computer that hosts a web site may be the server.
For example, when you enter a URL in your browser, this actually sends an HTTP request to the Web server then the server returns a response to the client. The response contains status information about the request and may also contain the requested content.
A similar abbreviation, HTTPS means Hyper Text Transfer Protocol Secure. Basically, it is the secure version of HTTP. Communications between the browser and website are encrypted by Transport Layer Security (TLS), or its predecessor, Secure Sockets Layer (SSL).
In GET method the browser will add the form contents (name/value pairs) to the end of the URL. This is the default method.
GET is generally used for simple forms where security is not a concern. GET offers a number of advantages for simple forms.
In POST method contents are not displayed in the URL. You should always use POST if the form data contains sensitive or personal information.
The data sent to the server with POST is stored in the request body of the HTTP request.
POST /filter.php HTTP/1.1 Host: example.com name1=value1&name2=value2
Are you confused between GET and POST methods??
Don't worry, fill and submit these forms and see how it works:
The following table compares the two HTTP methods: GET and POST
|History||Parameters remain in browser history because they are part of the URL||Parameters are not saved in browser history|
|Bookmarked||Can be bookmarked||Can not be bookmarked|
|BACK button/Reload||GET requests are re-executed but may not be re-submitted to server if the HTML is stored in the browser cache||The browser usually alerts the user that data will need to be re-submitted|
|Encoding type||application/x-www-form-urlencoded||application/x-www-form-urlencoded or multipart/form-data. Use multipart encoding for binary data|
|Restrictions on data length||Yes, since form data is in the URL and URL length is restricted. A safe URL length limit is often 2048 characters but varies by browser and web server||No restrictions|
|Restrictions on form data type||Yes, only ASCII characters allowed||No restrictions. Binary data is also allowed|
|Security||GET is less secure compared to POST because data sent is part of the URL. So it's saved in browser history and server logs in plaintext||POST is a little safer than GET because the parameters are not stored in browser history or in server logs|
|Visibility||Data is visible to everyone in the URL||Data is not displayed in the URL|
|Cached||Can be cached||not cached|
|Usability||GET method should not be used when sending passwords or other sensitive information||POST method used when sending passwords or other sensitive information|
PUT is used to send data to a server to create/update a resource.
The difference between POST and PUT is that PUT requests are idempotent. That is, calling the same PUT request multiple times will always produce the same result. In contrast, calling a POST request repeatedly have side effects of creating the same resource multiple times.
The OPTIONS method describes the communication options for the target resource.
The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. The metainformation contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request. This method can be used for obtaining metainformation about the entity implied by the request without transferring the entity-body itself. This method is often used for testing hypertext links for validity, accessibility, and recent modification.
The response to a HEAD request MAY be cacheable in the sense that the information contained in the response MAY be used to update a previously cached entity from that resource. If the new field values indicate that the cached entity differs from the current entity (as would be indicated by a change in Content-Length, Content-MD5, ETag or Last-Modified), then the cache MUST treat the cache entry as stale.
The DELETE method requests that the origin server delete the resource identified by the Request-URI. This method MAY be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully. However, the server SHOULD NOT indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible location.
A successful response SHOULD be 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if the action has not yet been enacted, or 204 (No Content) if the action has been enacted but the response does not include an entity.
If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries SHOULD be treated as stale. Responses to this method are not cacheable.
Last updated: Tuesday 28 Aug, 2018