正如其他人回答的那样，get对url大小有限制，文件只能通过post提交。

我想补充的是，一个人可以添加东西到一个数据库的get和执行操作与发布。当脚本接收到post或get命令时，它可以执行作者希望它执行的任何操作。我相信缺乏理解来自于这本书选择的措辞或你的阅读方式。

脚本作者应该使用posts来更改数据库，而只使用get来检索信息。

脚本语言提供了许多访问请求的方法。例如，PHP允许使用$_REQUEST来检索post或get。应该避免使用更具体的$_GET或$_POST。

在web编程中，有更多的解释空间。一个人应该做什么，可以做什么，但哪一个更好往往是有争议的。幸运的是，在这种情况下，没有歧义。您应该使用posts来更改数据，并且应该使用get来检索信息。

在PHP中，POST数据限制通常由PHP .ini设置。GET受到服务器/浏览器设置的限制——通常在255字节左右。

我的一般经验法则是，当您向服务器发出不打算改变状态的请求时使用Get。post是为更改状态的服务器请求保留的。

阅读维基百科上关于HTTP的文章。它将解释协议是什么以及它的作用:

得到 请求指定资源的表示形式。请注意，GET不应该用于导致副作用的操作，例如在web应用程序中使用它来执行操作。其中一个原因是，GET可以被机器人或爬虫任意使用，它们不需要考虑请求应该引起的副作用。

and

帖子 向已识别的资源提交要处理的数据(例如，来自HTML表单)。数据包含在请求体中。这可能导致创建新资源或更新现有资源，或者两者都有。

W3C有一个名为uri、Addressability的文档，以及HTTP GET和POST的使用，它解释了什么时候使用什么。引用

1.3 HTTP GET / POST选择快速检查 在以下情况下使用GET: 这种互动更像是一个问题(也就是说，它是一个问题) 安全操作，如查询、读取操作或查找)。

and

在以下情况下使用POST: 这种互动更像是一种命令，或者 交互以用户可以感知的方式改变资源的状态(例如，对服务的订阅)，或者 o用户对互动的结果负责。 但是，在最终决定使用HTTP GET还是POST之前，还请考虑敏感数据和实际考虑因素。

一个实际的例子是每当您提交HTML表单时。您可以为表单操作指定post或get。PHP将相应地填充$_GET和$_POST。

正如其他人回答的那样，get对url大小有限制，文件只能通过post提交。

我想补充的是，一个人可以添加东西到一个数据库的get和执行操作与发布。当脚本接收到post或get命令时，它可以执行作者希望它执行的任何操作。我相信缺乏理解来自于这本书选择的措辞或你的阅读方式。

脚本作者应该使用posts来更改数据库，而只使用get来检索信息。

脚本语言提供了许多访问请求的方法。例如，PHP允许使用$_REQUEST来检索post或get。应该避免使用更具体的$_GET或$_POST。

在web编程中，有更多的解释空间。一个人应该做什么，可以做什么，但哪一个更好往往是有争议的。幸运的是，在这种情况下，没有歧义。您应该使用posts来更改数据，并且应该使用get来检索信息。

短的版本

GET:通常用于已提交的搜索请求，或者任何您希望用户能够再次调出确切页面的请求。

GET的优点:

url可以安全地添加书签。 页面可以安全地重新加载。

GET的缺点:

变量作为名称-值对通过url传递。(安全风险) 可以传递的变量数量有限。(基于浏览器。例如，Internet Explorer被限制为2048个字符。)

POST:用于更高安全性的请求，其中数据可能用于更改数据库，或者您不希望别人添加书签的页面。

POST的优点:

url中不显示名称-值对。(安全+= 1) 可以通过POST传递无限数量的名称-值对。参考。

POST的缺点:

使用POST数据的页面不能被书签。(如果你愿意的话。)

完整版

直接来自超文本传输协议——HTTP/1.1:

9.3 GET The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI. If the Request-URI refers to a data-producing process, it is the produced data which shall be returned as the entity in the response and not the source text of the process, unless that text happens to be the output of the process. The semantics of the GET method change to a "conditional GET" if the request message includes an If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, or If-Range header field. A conditional GET method requests that the entity be transferred only under the circumstances described by the conditional header field(s). The conditional GET method is intended to reduce unnecessary network usage by allowing cached entities to be refreshed without requiring multiple requests or transferring data already held by the client. The semantics of the GET method change to a "partial GET" if the request message includes a Range header field. A partial GET requests that only part of the entity be transferred, as described in section 14.35. The partial GET method is intended to reduce unnecessary network usage by allowing partially-retrieved entities to be completed without transferring data already held by the client. The response to a GET request is cacheable if and only if it meets the requirements for HTTP caching described in section 13. See section 15.1.3 for security considerations when used for forms. 9.5 POST The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the following functions: Annotation of existing resources; Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles; Providing a block of data, such as the result of submitting a form, to a data-handling process; Extending a database through an append operation. The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI. The posted entity is subordinate to that URI in the same way that a file is subordinate to a directory containing it, a news article is subordinate to a newsgroup to which it is posted, or a record is subordinate to a database. The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity that describes the result.