POST (HTTP)

The world wide Web and HTTP are based on a number of request methods or 'verbs', including POST and GET as well as PUT, DELETE, and several others. Web browsers normally use only GET and POST, but RESTful online apps make use of many of the others. POST's place in the range of HTTP methods is to send a representation of a new data entity to the server so that it will be stored as a new subordinate of the resource identified by the URI.[1] For example, for the URI http://example.com/customers, POST requests might be expected to represent new customers, each including their name, address, contact details and so on. Early website designers stayed away from this original concept in two important ways. First, there is no technical reason for a URI to textually describe the web resource subordinate to which POST data will be stored. In fact, unless some effort is made, the last part of a URI will more likely describe the web application's processing page and its technology, such as http://example.com/applicationform.php. Secondly, given most web browsers' natural limitation to use only GET or POST, designers felt the need to re-purpose POST to do many other data submission and data management tasks, including the alteration of existing records and their deletion.

Efforts by some influential writers to remedy the first point began as early as 1998.[2] Web application frameworks such as Ruby on Rails and others make it easier for designers to provide their users with semantic URLs. With regard to the second point, it is possible to use client-side scripting, or to write standalone apps, to make use of the other HTTP methods where they are relevant,[3] but outside of this most web forms that submit or alter server data continue to use POST for the purpose.

That is not to say that every web form should specify method="post" in its opening tag. Many forms are used to specify more precisely the retrieval of information from the server, without any intention of altering the main database. Search forms, for example, are ideally suited to having method="get" specified.[4]

There are times when HTTP GET is less suitable even for data retrieval. An example of this is when a great deal of data would need to be specified in the URL. Browsers and web servers can have limits on the length of the URL that they will handle without truncation or error. Percent-encoding of reserved characters in URLs and query strings can significantly increase their length, and while Apache HTTP Server can handle up to 4,000 characters in a URL,[5] Microsoft Internet Explorer is limited to 2,048 characters in any URL.[6] Equally, HTTP GET should not be used where sensitive information, such as user names and passwords, have to be submitted along with other data for the request to complete. Even if HTTPS is used, preventing the data from being intercepted in transit, the browser history and the web server's logs will likely contain the full URL in plaintext, which may be exposed if either system is hacked. In these cases, HTTP POST should be used.[7]

When a web browser sends a POST request from a web form element, the default Internet media type is "application/x-www-form-urlencoded".[8] This is a format for encoding key-value pairs with possibly duplicate keys. Each key-value pair is separated by an '&' character, and each key is separated from its value by an '=' character. Keys and values are both escaped by replacing spaces with the '+' character and then using percent-encoding on all other non-alphanumeric[9] characters.

For example, the key-value pairs

Name: Gareth Wylie
Age: 24
Formula: a+b == 21

are encoded as

Name=Gareth+Wylie&Age=24&Formula=a%2Bb+%3D%3D+21

Starting with HTML 4.0, forms can also submit data in multipart/form-data as defined in RFC 2388 (See also RFC 1867 for an earlier experimental version defined as an extension to HTML 2.0 and mentioned in HTML 3.2).

The special case of a POST to the same page that the form belongs to is known as a postback.

Per RFC 7231, the POST method is not idempotent, meaning that multiple identical requests might not have the same effect than transmitting the request only once. POST is therefore suitable for requests which change the state each time they are performed, for example submitting a comment to a blog post or voting in an online poll. GET is defined to be nullipotent, with no side-effects, and idempotent operations have "no side effects on second or future requests".[10][11] For this reason, web crawlers such as search engine indexers normally use the GET and HEAD methods exclusively, to prevent their automated requests from performing such actions.

However, there are reasons why POST is used even for idempotent requests, notably if the request is very long. Due to restrictions on URLs, the query string the GET method generates may become very long, especially due to percent-encoding.[10]

• Straightforward definition of POST
• POST verb in HTTP specification
• URIs, Addressability, and the use of HTTP GET and POST[1]