我们的系统只允许用get post，一旦支持delete put head等，立马开除，因为第三方安全公司认为这是重大风险！

Put和Delete也常用，而且要注意的是Post不是幂等操作。当客户端有重试需求时，API设计要尽量避免Post，改用Put。

这个问题，我也来回答下。我从98年开始编程，到现在仍在搞软件行业。

WebAPI是否就应该用GET和POST，或者是GET.POST.PUT.DELETE？我认为这些都是动作，URL地址是资源。从这个角度来说，应使用后者。但是现实世界并不只有增删改查，还有审核，驳回，批量更新，开始，结束等等。这些动作应该和现实世界的业务动作保持一致，这样才是好的设计，有统一的接口外观。

但是HTTP不支持扩展啊，所以很尴尬。

那么为了统一接口外观，只能是查询是GET，凡是对数据有影响的都用POST，具体业务动作放在URL最后，或许这才是好的接口设计。

因此我认为不必要为了restful而一定要用put和delete。

只是外观上的事情，问题不大。

纯手打，不同意见多谢告知，让我也学习学习！

打个比喻:世界上有那么多的刀，你却认为家里的菜刀(get、post)最牛逼，菜刀在手，走遍天下，反正能用，却不管什么场景用什么刀最好用，最方便，好比剪指甲，明明指甲刀更好，而你拿起菜刀照样干。。。

我知道有put,delete,不过一个月的活要我一周干完，管不了那么多了，直接复制黏贴拉倒

打开调试工具我们可以看到除了get和post，还有put、delete方法，那为啥只用到get和post呢？

我们先搞清楚这些方法的用处，在讨论它们的使用。

GET：从服务器检索内容或者实体在HTTP术语。GET请求通常不包含请求体，但是是被允许的。一些网络缓存设备仅仅GET方式响应。GET请求通常不会导致服务器数据变化。

POST：用客户端提供的数据更新实体。一个POST请求通常在请求体中包含信息，这些信息在应用服务器是可以被使用的。POST请求被认为是非幂等性的，意味着如果多个请求被处理和仅仅一个请求被处理结果是不一样的。

PUT：添加一个由客户端提供的数据实体。一个PUT请求通常在请求体包含服务器用来创建新实体用的信息。通常，PUT请求被认为是幂等性的，意味着请求可以反复使用相同应用的结果。

DELETE：删除一个基于URI内容的实体或者由客户端提供的请求体。DELETE请求通常在REST服务请求接口。

其实还有其他一些方法，多是辅助使用的，这里就不谈论了。

可以看到这四个方法分别对应增、删、改、查功能，下面来逐个分析。

GET请求，提供查询功能，可将查询条件拼接在url后面。url是有字符长度限制的，长度根据浏览器和服务器决定，其次由于url是完全暴露的，从安全角度看，涉及重要信息或资源的接口，不推荐使用。

POST请求，是非幂等性的，可局部更新资源也可全量更新资源，非常灵活，而且数据传输使用json格式，非常直观易懂，这也是很多接口采用POST请求的原因。

PUT请求，是幂等性，请求多次结果都是相同的，在实用时有很大的局限性，一般用于非常重要的防重的操作接口，比如发起支付，由于客户端的抖动或其他原因导致重复请求接口，这时可以用PUT请求，但这也导致很多逻辑处理必须在服务器实现，大大降低了服务器的效率，其实防止重复请求接口可以用其他的简便方法处理，这里就不展开谈论了。

DELETE请求，也是幂等性，一般很少有需要删除资源的需求，其次在实用中也很鸡肋。

通过以上分析可以看出，使用最多的POST请求，确实是因为它使用方便，当然也更开发者的习惯有关。以上四个方法，我司都有使用，主要是POST请求为主，其他三个方法根据特定需求使用的。

我是非著名工程师，希望我的回答对你有所帮助，欢迎点赞关注支持，感谢！

对于软件开发行业而言离不开接口（API）的存在，开发人员肯定用过第三方的API也曾自己写过API给其它人调用。就现在而言，API基本上都是Web API形式，而API请求方式以GET和POST居多。但要说接口编程只用GET和POST，这种观点就是错误的！

Web API是当前主流的接口形式

我们常说的“接口”其实是指应用程序接口，也就是API。API将某种业务功能封装起来便于第三方调用，任何一门编程语言都可以用来开发API接口，而API接口的形式众多，较常见的有：

1、基于HTTP协议的Web API

基于HTTP协议的API现在应用最广，因为这类API是跨平台跨语言的，看上去就和URL差不多。当下流行的RESTful API其实也属于Web API，通过HTTP动词（GET、POST、DELETE、PUT等）来表达不同类型的请求。

2、RPC 接口

RPC指的是远程过程调用，本质上是“客户端/服务器端”模式（C/S模式），通过RPC技术可以让调用方像调用本地方法一样快捷的调用远程服务器上的方法。

RPC类接口也支持多种协议（如：HTTP、TCP、UDP、或自定义协议），数据传输方式也是多种多样的（最常用的是 Json、Binary、Protobuf ）。

3、Web Service 概念类接口

Web Service 其实并不是特指某一个技术，而是一类以Web形式提供的服务都可以称之为Web Service，像上面说的Web API、RESTful、SOAP等都属于Web Service范畴。

为什么Web API最常用的请求类型是GET和POST？

的确，Web API请求时最常用的请求类型（HTTP动词）是GET、POST。在RESTful风格推出之前，我们的接口传参是少数的一般用GET请求，参数较多的就用POST请求。

但随着RESTful风格推出后，我们是用不同的HTTP动词来代表不同的请求，如：

• GET：获取资源
  

• POST：创建资源

• PUT：更新资源

• DELETE：删除资源

但为什么感觉GET和POST居多呢？原因有以下几点：

• 现在还有很多Web API没有按照RESTful风格建议来编写API；
  

• 即使是RESTful风格类型的API，PUT、DELETE这类动词其实也是建议在POST动词基础之上的。

以上就是我的观点，对于这个问题大家是怎么看待的呢？欢迎在下方评论区交流 ~ 我是科技领域创作者，十年互联网从业经验，欢迎关注我了解更多科技知识！

就为这事，上家公司一前端和后端干起来了，后端写了一接口，用put请求方式，前端开发在火狐浏览器上提示跨域，跨域是nginx统一处理的，换google浏览器、360浏览器都正常访问。然后就让后端看看，后端这哥们不管三七二十一，说在postman请求是ok的，前端这个时候不干了，你这接口访问跨域意味着接口不通呀，要求换成POST，后端同学不干，说我这个是遵循resultful规范的，修改数据就得用PUT，不应该是POST，而且我用postman请求是ok的。

问题来了，这种事情到底是前端处理还是后端处理？

从技术角度来说，我们应该是解决问题，而不应该规避问题对吧？

解决问题的前提是得发现产生问题得本质原因是什么，如果问题能解决，大家就一起解决，如果这个问题属于三方问题，那就只能去规避这个问题。

后来经过大家检查发现是火狐浏览器的一个小bug，不容易复现，那这个问题没法解决了，这个时候就协商让后端改成POST试试，那后端就愿意改了。

后端这哥们的态度就是：“你要说你不行，那咱就给你解决，但是你不能说是我的问题”。

故事说完了～

restful应不应该用？

我个人是倾向于在接口编程中只用get和post的，任你resultful规范的接口说的天花乱坠，可是我写的接口就两种：数据查询就GET，数据变更就POST。但是我也从不限制别人使用PUT、DELETE请求。

但是需要有一些注意的地方，比如有的接口统计是基于nginx日志的，那么resultful风格的接口可能给统计带来一些问题或者额外的工作量。

例如一个商品详情接口：GET xxx/goods/1

你说你要统计这个接口的访问数量，就得走匹配模式，如果是多参数的，或者没有规则前缀的那就无法统计了。

还有的老项目，接口交互用的是表单形式，而不是application/json，那就是清一色的post接口，你也别想着什么规范不规范了。

最重要的一点：接口是写给客户端用的，要和客户端多商量，定义好接口文档。

Get，post就足够用了。。搞什么restful规范的接口，活干完就不错了，别整那些花里胡哨的