扫码关注官方订阅号
RT 恩。就是这样
闭关修行中......
与其他人观点不同。两个理由：
懒了，后面的东西其实是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等，但指责一个本身就不正常的设备有小毛病，是没有意义的。
吃饭的家伙有上百种，为什么我们常用的只有筷子和勺子？
一样的，跟着需求走
只能说明我们做的应用还不够复杂而已，这个我们感觉像http的状态码一样，你使用不到其他提交方式的场景，所以你觉得常用的就这些了。
单状态码系列2开头的就有好多项，我们平常也就区分了200，并不是说 203 ，204没有用，实际是我们的应用并未有这方面的需求
因为你没用到其他的
如果你有一些特殊应用，比如ssh over http，可能就会用到CONNECT
如果做WebDAV之类东西，你更会看到远多于"8种"方法
还有种可能是.. 其实用了, 你不知道
比如CORS请求的preflight就用了OPTIONS
delete那些主要是RESTFUL风格用到的，一般还是用名字区分,例如add,list,delete
（转载，真实原创来源已找不到。）
很多人都没有按照HTTP规范（http://www.ietf.org/rfc/rfc26...）去做。导致这个问题的原因有很多，比如说：
很多人贪方便，更新资源时用了GET，因为用POST必须要到FORM（表单），这样会麻烦一点。
对资源的增，删，改，查操作，其实都可以通过GET/POST完成，不需要用到PUT和DELETE。
早期的Web MVC框架设计者们并没有有意识地将URL当作抽象的资源来看待和设计，所以导致一个比较严重的问题是传统的Web MVC框架基本上都只支持GET和POST两种HTTP方法，而不支持PUT和DELETE方法。
以上3点都是没有严格遵守HTTP规范，随着架构的发展，出现了REST(Representational State Transfer)，一套支持HTTP规范的RESTful架构。
RESTful通常用post,put,delete和get
然而很多人其实是这么做的，这样一来自然都用post就可以搞定了。xxxx/users/addxxxx/users/editxxxx/users/deletexxxx/users/getList...
许多的早期教程也只提到过post和get，以讹传讹，代代相传咯
因为大家都很懒，然后美其名曰 筷子、勺子、叉子都可以吃饭，勺子吃面条，虽然不伦不类，但是能吃啊。
其实，项目不复杂的话，post一种就搞定了，get也可以不用！
微信扫码关注PHP中文网服务号
QQ扫码加入技术交流群
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
PHP学习
技术支持
返回顶部
0 
9
863
收藏
与其他人观点不同。两个理由：
除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等，但指责一个本身就不正常的设备有小毛病，是没有意义的。
吃饭的家伙有上百种，为什么我们常用的只有筷子和勺子？
一样的，跟着需求走
只能说明我们做的应用还不够复杂而已，这个我们感觉像http的状态码一样，你使用不到其他提交方式的场景，所以你觉得常用的就这些了。
单状态码系列2开头的就有好多项，我们平常也就区分了200，并不是说 203 ，204没有用，实际是我们的应用并未有这方面的需求
因为你没用到其他的
如果你有一些特殊应用，比如ssh over http，可能就会用到CONNECT
如果做WebDAV之类东西，你更会看到远多于"8种"方法
还有种可能是.. 其实用了, 你不知道
比如CORS请求的preflight就用了OPTIONS
delete那些主要是RESTFUL风格用到的，一般还是用名字区分,例如add,list,delete
（转载，真实原创来源已找不到。）
很多人都没有按照HTTP规范（http://www.ietf.org/rfc/rfc26...）去做。导致这个问题的原因有很多，比如说：
很多人贪方便，更新资源时用了GET，因为用POST必须要到FORM（表单），这样会麻烦一点。
对资源的增，删，改，查操作，其实都可以通过GET/POST完成，不需要用到PUT和DELETE。
早期的Web MVC框架设计者们并没有有意识地将URL当作抽象的资源来看待和设计，所以导致一个比较严重的问题是传统的Web MVC框架基本上都只支持GET和POST两种HTTP方法，而不支持PUT和DELETE方法。
以上3点都是没有严格遵守HTTP规范，随着架构的发展，出现了REST(Representational State Transfer)，一套支持HTTP规范的RESTful架构。
RESTful通常用post,put,delete和get
然而很多人其实是这么做的，这样一来自然都用post就可以搞定了。
xxxx/users/add
xxxx/users/edit
xxxx/users/delete
xxxx/users/getList
...
许多的早期教程也只提到过post和get，以讹传讹，代代相传咯
因为大家都很懒，然后美其名曰 筷子、勺子、叉子都可以吃饭，勺子吃面条，虽然不伦不类，但是能吃啊。
其实，项目不复杂的话，post一种就搞定了，get也可以不用！