http请求有8种，为什么我们现在常用的就只有get post了呢

Question

RT 恩。就是这样

Answer 1

与其他人观点不同。两个理由：

除Get和Post之外的请求方式，我们是有很多情况下需要用到，然而多数人使用了非正常手段实现了。

懒了，后面的东西其实是RESTFUL，请自行脑补。

按照定义，假设有资源组A，内部包含该1、2、3这些资源，则

获取资源A1：Get Url A1
新增资源A4：Post Url A + RAWDATA 4
修改资源A4：Put Url A + RAWDATA 4
删除资源A2：Delete Url A2

然而实际上多数人都这么做

获取资源A1：Get Url A1
新增资源A4：Post Url A + RAWDATA 4
修改资源A4：Post Url A4 + RAWDATA 4
删除资源A2：Get Url delete A1

即使是新浪的微博都 POST Url+access_token + RAWDATA empty 的方式使用。

更多的人都在用 Get + delete 参数的方式来实现，不知道他们的理由是不知道、不理解、还是不愿意。

网络恶劣

你知道其实很多情况下我们网络的80端口是被劫持的么，而二级运营商则几乎100%都是被劫持的。某些设备劫持之后会代理你进行http访问，而这些设备是 不认识 其他请求方式的。

我见过的一个二级运营商，他的劫持设备，就只认识3种请求方式，Get、Post、Connection，如果遇到其他请求方式，就会返回你403错误或者500或者502。像现在有大量的跨域请求需要Option，遇到这种网络就完全报废了。本身这里就很不正常了，然而它返回的状态码也是错的，错误的请求方式，一般都是400、405等，但指责一个本身就不正常的设备有小毛病，是没有意义的。

---

补充：

是时候祭出这张照片了

这是我司现在最受重视的项目的express路由代码的一段截图：

顺带一提我负责的那个项目后端是用RESTFUL写的，项目还在，但是开发人员已经“又”没了，设备也都被拆了。

Answer 2

吃饭的家伙有上百种，为什么我们常用的只有筷子和勺子？

一样的，跟着需求走

Answer 3

delete那些主要是RESTFUL风格用到的，一般还是用名字区分,例如add,list,delete

Answer 4

只能说明我们做的应用还不够复杂而已，这个我们感觉像http的状态码一样，你使用不到其他提交方式的场景，所以你觉得常用的就这些了。

单状态码系列2开头的就有好多项，我们平常也就区分了200，并不是说 203 ，204没有用，实际是我们的应用并未有这方面的需求

Answer 5

因为你没用到其他的

如果你有一些特殊应用，比如ssh over http，可能就会用到CONNECT

如果做WebDAV之类东西，你更会看到远多于"8种"方法

---

还有种可能是.. 其实用了, 你不知道

比如CORS请求的preflight就用了OPTIONS

Answer 6

（转载，真实原创来源已找不到。）

很多人都没有按照HTTP规范（http://www.ietf.org/rfc/rfc26...）去做。导致这个问题的原因有很多，比如说：

1. 很多人贪方便，更新资源时用了GET，因为用POST必须要到FORM（表单），这样会麻烦一点。

2. 对资源的增，删，改，查操作，其实都可以通过GET/POST完成，不需要用到PUT和DELETE。

3. 早期的Web MVC框架设计者们并没有有意识地将URL当作抽象的资源来看待和设计，所以导致一个比较严重的问题是传统的Web MVC框架基本上都只支持GET和POST两种HTTP方法，而不支持PUT和DELETE方法。

以上3点都是没有严格遵守HTTP规范，随着架构的发展，出现了REST(Representational State Transfer)，一套支持HTTP规范的RESTful架构。

Answer 7

RESTful通常用post,put,delete和get

然而很多人其实是这么做的，这样一来自然都用post就可以搞定了。
xxxx/users/add
xxxx/users/edit
xxxx/users/delete
xxxx/users/getList
...

许多的早期教程也只提到过post和get，以讹传讹，代代相传咯

Answer 8

因为大家都很懒，然后美其名曰 筷子、勺子、叉子都可以吃饭，勺子吃面条，虽然不伦不类，但是能吃啊。