c 做网站如何调用dll,长兴县住房和城乡建设局 网站,平安车险官方保险网站,阿里云模板建站文章目录 前言get 与 post 的区别所有接口都用 post 请求#xff1f;网友程墨 Morgan网友苏莉安网友大宽宽 前言
最近在逛知乎的时候发现一个有趣的问题#xff1a;公司规定所有接口都用 post 请求#xff0c;这是为什么#xff1f;
看到这个问题的时候其实我也挺有感触的… 文章目录 前言get 与 post 的区别所有接口都用 post 请求网友程墨 Morgan网友苏莉安网友大宽宽 前言
最近在逛知乎的时候发现一个有趣的问题公司规定所有接口都用 post 请求这是为什么
看到这个问题的时候其实我也挺有感触的因为我也曾经这样问过我自己。在上上一家公司的时候接到一个项目是从零开始搭建一个微服务当时就有了解过接口的一些规范比如耳熟能详的 Restful 规范就被应用到这个微服务项目中。 get 与 post 的区别
今天再次看到这个问题我也有了一些新的理解和感触临时回顾了一下 get 与 post 的请求的一些区别。 如下
post 更安全不会作为 url 的一部分不会被缓存、保存在服务器日志、以及浏览器浏览记录中post 发送的数据更大get 有 url 长度限制post 能发送更多的数据类型get 只能发送 ASCII 字符post 比 get 慢post 用于修改和写入数据get 一般用于搜索排序和筛选之类的操作get 请求的是静态资源则会缓存如果是数据则不会缓存
查看上面的区别就会发现 post 在发送数据量大的请求时优势很明显get 则更适合获取静态资源、简单的查询等接口。
我个人在开发接口的时候也会注意将简单的查询请求使用 get 方法其他增、删、改、复杂的查询请求都可以使用 post但不会像题主的公司一样全部使用 post。
所有接口都用 post 请求
网友程墨 Morgan
网友程墨 Morgan 提出如果是自己会按照『业界最佳实践』制定规范 网友苏莉安
另外一个知友提出就是为了迁就低水平不思进取的架构师和前后端程序员们。
网友大宽宽
大宽宽的回答我打算跳出技术的范畴从 ROI 的角度讨论下如果一个架构风格比如 Restful真的那么好为啥应用上没有那么广泛 首先要明确不管你多么喜欢技术无论是这里说的一个 http 的 method又或者是编程语言的一些用法、架构设计方法、甚至是 OKR 这样的管理和沟通的方法。这一切都是为了满足企业对市场的需求。
简单来说公司给你发工资不是为了让你遵守规范的而是为了能在成本可接受的情况下让业务落地。而其中一般情况下接口的形式是个微不足道的局部问题。
对于企业来讲技术团队要解决的更重要的问题
是理解业务模型形成业务架构和可以稳定跑的系统是面对大量涌入用户对系统可用性的要求对系统不会卡顿挂机的扩展性保障是不会动不动抽疯一下丢条数据或者数据冲突的稳定性要求以及为了达成这些要求给监控体系的各种便利。
但一定要纠结下 POST/GET以及 Restful。好吧Restful 能明确列出来的好处就那么几点如果有疏漏的请在评论区里补充。
如下
表达不同的业务动作语义GET/POST/PATCH/PUT/DELETE……表达“资源”的概念利用url pathquerystringheaderstatus code 等来表达很多接口功能以上两条可以达成一种“统一”的接口表达形式以至于可以围绕这个形式实现接口维护的工具比如 swagger。Get 资源可以利用缓存
但代价是什么
①强行的统一让本来天然不是资源的业务概念也一定要强行“资源“一下引发了更多的理解不一致和沟通困难。
当然事物总是可以“抽象”一下业务概念抽象为“资源”很多时候都是可行的。但这这么做的收益除了证明“一个人聪明有不错的抽象能力“以及“更容易利用上 swagger 一类的工具“之外我看不到啥额外的短期或者长期收益。
②乱折腾 pathquerysting 等东西让横切面治理抓取关键信息更难了。 比如监控时抓一个 path 里带变量的 url 是非常恶心的事情。
又或者看到一个 404 的报警却根本搞不清楚到底是服务部署有问题还是服务正常但用户不存在又或者是用户存在但用户订单不存在。带来的问题是运营工具编写困难线上问题响应能力会被降低。
③即使使用 swagger还是需要写说明和文档来说明其业务语义。 接口工具应该提供的“好理解接口改了后文档自动生成”等好处只有在接口反应的资源刚好和后台数据表/视图能够对应上才有效。
也就是说只适合接口层级低的场景下有用而对高层接口意义不大。结果开发者既要用 swagger 这样的工具同时还是要看常规文档。本来用一套机制可以解决的问题要改成两套。微信搜索公众号架构师指南回复架构师 领取资料 。
④Cache 虽好但最怕的是管控不到位让用户拿到了过期数据。 对于 Cache业务上一般会区分动态接口和静态接口。
前者默认不应该有 cache所以用了 Get 之后为了防范还得手工在大部分动态接口上加 Cache-Control: no-cache或者动态产生 ETag浪费 CPU。而后者一般会采用 CDN这一套针对 cache 做了很精巧的设计。
⑤使用形式各异的 method 和 url pathquerystring 上做各种奇怪的拼接会给前端带来巨大的困扰。
因为本来一个函数调用还得翻译一遍活生生的弄出来一个接口翻译层。妥妥的降低人效。如果是 webiOSAndroid 三套前端就得弄 3 个接口翻译层。
⑥非 GET 和 POST 之外的 method 有可能会被不恰当的网关转发规则给干掉。 为此 Restful 还是搞出了 method override 这样的招数……
所以到底适不适合落地时听骂声和吵架声就知道了。
有人举了 Google S3 运用 Restful 接口的例子来说明其正确性。但 S3 是干什么的大家都懂S3 天然就是用来存取“资源“的。
一个工具用在了恰当场景当然是“正确“的。S3 用的好的东西只能说明类似的阿里云 OSS腾讯云 COS 也可以这么干。但无法证明电商业务、社交业务、I 医疗业务、政企办公协同……这些业务也适合这么干。
而作为技术负责人如果他搞出了一套接口方案也许其中一条就是所有 http 接口都用 post提高了开发效率降低了沟通成本降低了运维和错误定位成本为企业真正做到了降本增效。
把瞎折腾的成本投入到了其他比如业务架构设计测试体系线上监控容灾降级等领域上。
最终让企业用户需求得到满足收入增加和员工得到了收益因为公司收入增加而涨薪。
我会评价这样的人为“真正懂架构懂技术善于用技术解决实际问题。水平不知道高到哪里去了”。
如果一个技术负责人只知道遵守一个书上写的但从没验证过在自己的环境有效的方案以至于让企业的核心目标无法达成。他就是赵括该马上卷铺盖卷走人。
至于我司使用的规范是 对于动态业务接口只有一个接口 POST/action在 Header 里给 X-Action 给出具体的接口名称交给网关路由session 表示用户登录身份以及用于推荐、防重、染色、安全用到的各种 token/签名。 所有的业务请求参数都以 PB 编码后放在请求体里并和后端的 gRPC 体系衔接。接口除了防重试之外不提供常规意义上的 Cache。
而对于静态接口走 CDN做多级 Cache。该用 Get 用 Get。如果一个动态接口也想利用 http 层 Cache可以向网关申请和配置。有没有 Cachecache 多久是网关和端上自己实施的完全自己管控。
各位读者可以参考看看并根据自己所处的业务场景和前后端交互思考下“我们目前用的技术规范是性价比最高的吗是最合适的吗“
如果是你来设计公司的 API 规范会规定所有接口都用 post 请求吗这是为什么
