据我所知,有三种类型:

不要使用GET和POST 不要使用POST而使用GET 你用哪一个都不重要。

我对这三种情况的假设正确吗?如果有,每个案例都有哪些例子?


当前回答

当我不希望人们看到QueryString或当QueryString变大时,我使用POST。另外,文件上传需要POST。

不过,我不认为使用GET有问题,我将它用于简单的事情,其中将内容保留在QueryString上是有意义的。

使用GET将允许链接到POST无法工作的特定页面。

其他回答

除了许多浏览器的长度限制不同之外,还有语义上的差异。get应该是“安全的”,因为它们是只读操作,不会改变服务器状态。post通常会改变状态,并在重新提交时给出警告。搜索引擎的网络爬虫可能会生成get,但不应该生成post。

如果希望读取数据而不改变状态,则使用GET;如果希望更新服务器上的状态,则使用POST。

POST可以移动大数据,而GET不能。

但一般来说,这不是关于GET的缺点,而是一种惯例,如果你想让你的网站/web应用程序表现良好。

看看http://www.w3.org/2001/tag/doc/whenToUseGet.html

Gorgapor, mod_rewrite仍然经常使用GET。它只是允许将一个更友好的URL转换为一个带有GET查询字符串的URL。

在短暂的

使用GET来获得安全的和无效的请求 对于既不安全也不幂等的请求使用POST


在细节 每个人都有一个合适的位置。即使您不遵循RESTful原则,通过学习REST以及面向资源的方法是如何工作的,也可以获得很多东西。

RESTful应用程序将对安全且幂等的操作使用get。

安全操作是不改变请求数据的操作。

幂等运算是一种无论你请求多少次结果都相同的运算。

有理由认为,由于get用于安全操作,它们自动也是幂等的。通常,GET用于检索资源(例如,堆栈溢出时的问题及其相关答案)或资源集合。

RESTful应用程序将使用put进行不安全但幂等的操作。

我知道这个问题是关于GET和POST的,但是我马上回到POST。

通常,PUT用于编辑资源(例如,在堆栈溢出上编辑问题或答案)。

POST可以用于任何既不安全也不幂等的操作。

通常,POST将用于创建一个新资源,例如创建一个new SO问题(尽管在某些设计中,PUT也会用于此)。

如果你运行POST两次,你最终会创建两个新的问题。

还有一个DELETE操作,但我猜我可以把它留在那里:)

讨论

实际上,现代网络浏览器通常只可靠地支持GET和POST(你可以通过javascript调用来执行所有这些操作,但是在表单中输入数据和按提交,你通常有两个选项)。在RESTful应用程序中,POST通常也会被覆盖以提供PUT和DELETE调用。

但是,即使您没有遵循RESTful原则,也可以考虑使用GET来检索/查看信息,使用POST来创建/编辑信息。

永远不要对改变数据的操作使用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.