HTML CSS Bootstrap Javascript Icons Python
HTML References
HTML - Tag Reference HTML - Tag by Category HTML - Attributes HTML - Global Attributes HTML - Events HTML - Language Codes HTML - Country Codes HTML - URL Encoding HTTP Methods HTTP Status Codes <input> types
All HTML Tags
<!-- --> <!DOCTYPE> <a> <abbr> <acronym> <address> <applet> <area> <article> <aside> <audio> <b> <base> <basefont> <bdi> <bdo> <big> <blockquote> <body> <br> <button> <canvas> <caption> <center> <cite> <code> <col> <colgroup> <data> <datalist> <dd> <del> <details> <dfn> <dialog> <dir> <div> <dl> <dt> <em> <embed> <fieldset> <figcaption> <figure> <font> <footer> <form> <frame> <frameset> <h1> - <h6> <head> <header> <hr> <html> <i> <iframe> <img> <input> <ins> <kbd> <label> <legend> <li> <link> <main> <map> <mark> <meta> <meter> <nav> <noframes> <noscript> <object> <ol> <optgroup> <option> <output> <p> <param> <picture> <pre> <progress> <q> <rp> <rt> <ruby> <s> <samp> <script> <section> <select> <small> <source> <span> <strike> <strong> <style> <sub> <summary> <sup> <svg> <table> <tbody> <td> <template> <textarea> <tfoot> <th> <thead> <time> <title> <tr> <track> <tt> <u> <ul> <var> <video> <wbr>

HTTP Request Methods

HTTP Request Method defines how data should be sent to the server. The two most used HTTP methods are: GET and POST.


What is HTTP?

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).


HTTP Methods


The GET method

In GET method the browser will add the form contents (name/value pairs) to the end of the URL. This is the default method.

http://example.com/filter.php?name1=value1&name2=value2

GET is generally used for simple forms where security is not a concern. GET offers a number of advantages for simple forms.



The POST method

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

GET vs POST

Are you confused between GET and POST methods??

Don't worry, fill and submit these forms and see how it works:

GET method:


POST method:


The following table compares the two HTTP methods: GET and POST

GET 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

Don't use GET method when sending sensitive information.

The PUT method

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

The OPTIONS method describes the communication options for the target resource.

The HEAD method

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

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