公司规定所有接口都用post请求，这是为什么(接口只能用public)

本文目录

1. 公司规定所有接口都用post请求，这是为什么
2. restful接口和普通接口有啥区别
3. 接口编程中，为什么只用get和post
4. POst机联接失败为什么

公司规定所有接口都用post请求，这是为什么

如果请求类型是text，GET和POST完全相同，不同点是在HTTP包的位置上，GET位于HTTPHEADER中，POST在BODY中。

因为GET是在header中，传送数据的长度有限制，而BODY是可以分片的，传送的数据长度就没有限制了。

如果是作为普通的接口协议，用GET更方便。

有人认为POST比GET安全性好，不存在的，两者都是明文传送，如果数据本身不加密，抓个包就看出来了。提高安全性的手段有两个：1、传输协议用https。2、对数据加校验和鉴权防止伪造。

restful接口和普通接口有啥区别

1、功能不同

restfulapi：restfulAPI是当作资源的唯一标识符。

传统api：传统API是为了实现某种功能。

2、methods多样性不同

restfulapi：RestfulAPImethods:

post创建数据

get获取数据

put/patch是更新数据

delete是删除数据

传统api：传统API只有get获取数据，其他都是POST解决。

3、接口不同

restfulapi：restfulAPI遵循统一接口的原则，禁止在API中使用自接口或多个接口。理想情况下，超媒体连接应用于分发单个接口。它还应确保类似的数据片段（例如，用户名或电子邮件地址）仅属于一个统一资源标识符（URI）。因此，无论初始请求如何，对相同资源的所有API请求都应看起来相同。简化了API接口的操作性和统一性：

api/file只需要这一个接口

GET方式请求api/file–获取文件信息，下载文件

POST方式请求api/file–上传创建文件

DELETE方式请求api/file–删除某个文件

传统api：传统接口：

api/getfile.php–获取文件信息，下载文件

api/uploadfile.php–上传创建文件

api/deletefile.php–删除文件

4、结构不同

restfulapi：restfulapi严格地在客户端和服务器的Web概念上运行。客户端和服务器彼此分离，提供了更大的灵活性。

传统api：在结构上，大多数API遵循应用程序–应用程序格式。

5、设计不同

restfulapi：restfulapi通过系统进行通信，使其成为一个复杂的架构。

传统api：API是轻量级体系结构，专为限制在智能手机等设备上的小工具而设计。

6、协议不同

restfulapi：restfulapi是一种架构风格，用于构建通过HTTP协议进行交互的Web服务。尽管restfulapi是由计算机科学家RoyFielding在2000年制定的，但它仍然是公共API的黄金标准。

传统api：API的主要目标是标准化Web服务之间的数据交换。根据API的类型，协议的选择会发生变化。

7、支持不同

restfulapi：即使用户不知道函数名称和参数的特定顺序，也会执行相比之下，即使用户不知道函数名称和参数的特定顺序，也会执行restfulAPI。

传统api：大多数API都很容易实现，因为它们不会面临无状态。

8、可扩展性不同

restfulapi：RESTAPI具有分层结构，使得RESTAPI模块化，并且更灵活地实现可扩展性。

传统api：可扩展性是通用API的一个问题。

API是一个更大的保护伞，restfulAPI是移动和云应用程序中普遍存在的独特类型的API。没有一个API是没有缺点的，但新的开发人员发现restfulAPI很困难，因为它无法在会话中保持状态。随着现代API成为符合特定标准和特定受众的产品，企业已迅速改进其用户界面。

接口编程中，为什么只用get和post

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

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

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

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

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

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

故事说完了～

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

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

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

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

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

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

POst机联接失败为什么

pos机出现通信ppp连接失败原因为：电话线未接好或通讯线路问题。解决方法为：

1、按电话机键盘也无声音，检查POS背后的电话线是否正确插入“电话/网络”插口；

2、可用电话机检查是否可听见电话拨号音；

3、如仍未解决请找通讯线路维修人员。注意：如还不能解决问题，可致电支付机构服务商解决。

公司规定所有接口都用post请求，这是为什么和post 接口 不建议的问题分享结束啦，以上的文章解决了您的问题吗？欢迎您下次再来哦！