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.
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.
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.
[2][better source needed] 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.
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.
[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.