百科问答小站 logo
百科问答小站 font logo



公司规定所有接口都用 post 请求,这是为什么? 第1页

  

user avatar   aton 网友的相关建议: 
      

只有一个原因,就是为了迁就低水平不思进取的架构师和前后端程序员们。

这问题底下好多津津乐道“这是多年一线开发经验总结出的最佳实践”的人恰好印证了这一点。


看了一下其他答案,全POST的理由大致分两类:

一是反RESTful,用POST替代PUT、DELETE、PATCH等;

姑且还有点道理,REST用Method表达语义其实是很清晰的,但它和传统RPC的思维方式并不直接兼容。而且两者也不是技术上的高低关系,无非是两种接口定义而已。

最怕的就是学个半吊子还简单粗暴硬要上REST,最后弄出个四不像,谁都理解不了。

但有人硬说PUT /api/object看不懂,只能看懂POST /api/updateObject,那只能说你确实该用一个POST包打天下。

如果一个团队有三成的人理解不了REST怎么写login,那还是放弃它吧,免得挖大坑。GET/POST也是很清晰的语法体系啊。


另一种是反GET,理由无外乎url长度和缓存,这就更让人迷惑了。

url长度问题基本都出现在多参数检索中。但是,哪怕用REST语义来分析,复杂检索也本来就该用POST。因为“检索条件-结果”是资源本身而不是一个资源列表,你创建了检索id后可以缓存结果并再次用GET获取。这种原本解决方案十分清晰的问题居然被解释为“GET放不下,我们用POST代替吧”,哭笑不得。

缓存才是不可思议的:无论移动端还是web端都有起码五六种方法来阻止缓存,你可以添加Header,可以在url加时间戳或随机数,可以用Etag,再不济可以手工清除。居然能被这个问题困住而不得不改用POST,莫非只会用浏览器调试API?


全接口POST化绝大部分时候就是为了迁就低水平技术人员。但这种说法有点伤自尊,所以往往会拿“公司统一规定”搪塞。表面显得又标准又规范,实际内里什么样很多人都清楚。

“标准太麻烦,所以堂而皇之地扔掉标准另起炉灶还以此为傲”,这种草台班子心态对一个技术人员的成长是十分有害的。


说到这儿我忽然想起某个强制规定前端一律用div的团队。h1h2h3是div,p是div,label是div,button是div,span是inline的div。语义化是什么?不懂,没用。冠冕堂皇的理由自然是所谓的标准统一好管理不出错。然而为了防止样式混乱,文档里又详细规定了一堆title1、title2、label、btn的class……


user avatar   damon-dance-for-me 网友的相关建议: 
      

可能你们公司用了GraphQL吧


user avatar   Ivony 网友的相关建议: 
      

两种可能:

1、我们现在确定一下,无副作用的查询接口,使用GET请求,有副作用的操作接口,使用POST请求。

老师,那登陆应该用GET咯?

不,登陆一般用POST请求,这是特例,因为登陆通常需要表单提交,而且登陆也不是完全无副作用,blablabla……

哦,那还有哪些特例呢?

…………

……

好,我们确定一下,以后一律用POST接口。


2、对于每个接口,我们都返回一个标准的JSON,其中有一个属性标注是否成功……同时HTTP响应码都为200 OK

哎呀,错误的结果被缓存了……

经研究决定,以后不准用GET请求……


user avatar   morgancheng 网友的相关建议: 
      

作为程序员,应该知道这种问题的准确答案应该去公司的架构师或者技术总监,他们有责任给一个解释,在知乎上问并不是正确的职业做法,知乎上啥人都有,他们的经历是他们的经历,你的公司是你的公司,你去问一个不相干的人你们公司的规定为什么,你不觉得......缘木求鱼吗?

不过,我可以给一些我自己的看法。

如果是在我现在的公司,我不会规定所有接口都是POST,我会按照『业界最佳实践』制定规范,幂等不修改服务器状态的用GET,幂等修改服务器状态的用PUT,不幂等修改服务器状态的用POST。

为啥要用『业界最佳实践』呢?

因为我司都是很牛的程序员啊,按照最科学的方式来做,才显得我们的公司尊重科学啊,按照业界最佳实践做,就是一种开放的姿态,广纳英才,我们的程序员也能够理解这样的规范,何乐而不为。

但是,如果让我去一个程序员水平良莠不齐的创业公司......我估计也会要求所有的接口都用POST请求。

这又是为啥呢?

因为我担心公司里这些打工人理解不了业界最佳实践,你和他们说幂等不修改服务器状态的用GET,幂等修改服务器状态的用PUT,不幂等修改服务器状态的用POST,他么会——

说了你又不听

听了你又不懂

懂了你又不做

做了你又做错

错了你又不认

认了你又不改

改了你又不服

不服你又不说

这样一种情况,我费那劲讲这些『业界最佳实践』的大道理干啥?

我也会简单粗暴用一种最不容易出错的方式,POST不会误用缓存,POST不受URL长度限制,POST能够用来获取也可以用来修改,那就用POST好了!

我不光规定用POST,还要通过工具强制要求用POST,API Server设置成除了POST请求都不接!

有时候就是这样最高效,费口水教育别人,还不如不给他们选择。

这科学吗?

不科学,这样不利于可持续发展,没有给员工犯错机会,所以他们难有成长。

但是话又说回来,有些程序员遇到公司技术规章问题,想到的都不是去问自己公司的架构师和技术总监,却跑到知乎上来问......也的确很难让他们成长。

再说了,员工没有犯错机会,作为创业公司的技术负责人一样没几次犯错机会了,系统搞成一坨浆糊了谁来背锅?

所以,两害取其轻,就这么简单粗暴地规定好了。

还好,我不再在创业公司工作了。


user avatar   will09 网友的相关建议: 
      

因为需要在维护初级技术人员自尊心的同时防止低级bug的出现。

很多初级程序员会选择在传参内容少的时候用GET,传参内容多的时候才使用POST,但这样一来,就会出现一些低级的bug,比如创建留言板发帖时url被缓存,导致重复发帖。

统一用POST,避免了URL缓存,也就避免了这类bug。但语义错误,会让了解语义规则的程序员觉得很不舒服,而且该用GET的地方用了POST,就没有了URL缓存,也就增加了服务器的负载压力。有些公司面试时问着如何处理高负载高并发问题,却连这种小细节都不要求,也确实是一件比较可笑的事情。

但是作为员工,没有必要去指出这一点,因为大多数公司,一千多的云主机就足够用了,压根不需要考虑负载问题。你要求公司修改这个规则,就是在说:“我不是针对谁,我是说在座各位……”

公司里知道语义规则的人应该是不少的,制定这条规则的人,心里应该也是清楚的。大家的目标都只是用最少的消耗去解决问题而已。

然后,题主既然提出了这个问题,应该是知道GET和POST的语义规则的,但是我还是在这里科普一下吧,毕竟这是一个负知识,公司里不敢说,网上总可以说一下的:

GET

  • 安全且幂等
  • 读取服务器内容时使用
  • 变更时获取表示(缓存)

POST

  • 不安全且不幂等
  • 使用服务端管理的(自动产生)的实例号创建资源
  • 创建子资源
  • 部分更新资源
  • 如果没有被修改,则不更新资源(乐观锁)

PUT

  • 不安全但幂等
  • 用客户端管理的实例号创建一个资源
  • 通过替换的方式更新资源
  • 如果未被修改,则更新资源(乐观锁)

DELETE

  • 不安全但幂等
  • 删除资源

HEAD

  • 安全且幂等
  • 递交获取资源的元数据

OPTIONS

  • 安全且幂等
  • 获取信息,关于资源的哪些属性是客户端可以改变的。

PATCH

  • 不安全,可以是不幂等的
  • 局部更新资源
  • 与PUT区别:只更新少部分内容;可能根据原数据进行变化(比如基本工资加200元),这时就不幂等了。

具体可以参见:


user avatar   taoshu0 网友的相关建议: 
      

首先这是Fed一月 memo

先说结论:

FOMC 维持利率在 0-0.25% 不变。且确定 3 月完全停止 QE,同时 3 月加息也是箭在弦上,基本会后声明皆符合市场预期,没有太多的意外。

Powell 记者会确实是偏一点点的小鹰派,但我也认为,Powell 的说法不至于拉升市场加息预期至 5次 、并拉升缩表预期至上半年,反而比较像是在强化加息 4 次之预期。

另外我个人觉得,一些中文媒体似乎误读了Powell 记者会的部分片段,下面 Allen 再进一步说明。


1. 3 月加息停止 QE 早已定价

本次会议 Fed 再次确认 3 月将准备第一次加息,并同时停止 QE。

Fed 也再次重申,货币政策是要支持美国经济达到充分就业、与通膨长期均值维持 2.0% 的两大目标。

这部分我想市场早已定价,这裡完全不会是问题,所以我们不讨论太多。


2.未来加息在每次会议都可能发生 (?)

Powell 的原文说法是:Won't Rule Out Hike Every Meeting.

但我有看到部分中文媒体写:不排除每次会议都加息的可能性。

上述我想或许是误读了 (还是其实是我自己误会中文的意思 ?)

我的理解是:Powell 是说加息在未来每场会议都可能发生,指的是“不会在特定月份才加息”,不是说每场都要加息。

Powell 说得很合理,经济本来就是动态的,加息本就不会侷限在什麽月份才启动,端看当时的经济状况而定。

我认为Powell 上述说法,并未延展今年加息预期至五次或更多,若有这种想法,那绝对是误读了。


3.更大规模的缩表?

Powell 在记者会上提到,Fed 需要更大规模的缩表,但请大家不要恐慌,因为我又觉得部份中文媒体过度解读了。

我认为Powell 说到的“更大规模缩表”,在思维上指的是:

因为当前 Fed 资产负债表高达 8.9 万美元,这是新冠疫情爆发之前的两倍大,显然在绝对规模上是非常巨大的。

而上一轮 2017-2019 年 Fed 缩减资产负债表,是自 4.4 万亿美元缩到 3.7 万亿美元停止,缩表的幅度大概是 15.9%,共缩减了约 7000 亿美元。

确实每次缩表的经济背景绝对是不一样的,所以幅度也绝对不会相同,但我们随便抓,假设本轮缩表将缩减 10% 资产负债表规模,那麽这也要降低 8900 亿美元,规模当然很大。

但我认为,不需要过度恐慌在“更大规模缩表”这几个字上。更重要的,我认为是“Fed 缩表的速率是多少?”

我相信缩表没问题,缩表太快才是问题,因为缩表速度若太快,将直接影响的会是美债殖利率升速、以及殖利率曲线的斜率。

这点Powell 也非常清楚,Powell 在记者会上也不断强调,联准会内部尚未具体讨论到一切缩表的进度,要等到 3 月再说。


4.缩表比较可能落在下半年

Powell 在记者会上说明,希望在加息至少一次之后,再来开会讨论缩表的事情,且委员会至少将讨论一次,才会做最终拍板。

更重要的,Powell 希望缩表的进程是有秩序的、是可被预见的过程。

从上述Powell 丢出的时间表看,我个人认为缩表将落在 2022 下半年,最快可能是 6 月份,因为在 3 月加息后,Fed 才会来讨论缩表。

我个人相信 Fed 现在内部早已在讨论缩表,但委员会显然尚未准备好来与市场沟通缩表的前瞻指引。

而缩表这麽大的事情,我个人认为 Fed 需要起次跟市场沟通 2 次,并把缩表规划说得非常清楚之后,才会开始进行,所以比较合理的缩表时间,估计将会落在下半年。


5.最大风险:高通膨

Powell 在记者会上,大概提到了 800 万次的“高通膨压力”,并认为目前美国通膨风险仍在上升阶段,但预计 2022 通膨还是会回落。

Powell 说明,目前美国通膨居高不下,主要仍是供应链所致,白话来说就是供需仍然失衡,且供给侧 (Supply Side) 改善的速度是低于预期。

Powell 强调,目前美国高通膨持续存在,而美国经济要的是长期扩张,所以若要长期扩张,物价势必需要保持稳定。

这边开始进入正题了,我认为这是本次会议的最重要核心,是让我体感上,觉得 Fed 鹰派的地方。我认为 Fed 承认自己落后给菲利浦曲线 (Behind the curve),简单而言,Fed 这次的加息速度大幅落后给通膨。

由于 Fed 在 2021 年对于通膨的误判,先前 Fed 在 2021 年认为通膨在年底就可望自然回落,但也就是因为这件事没有发生,反而通膨还更为严重,所以目前才有使用加息来追赶通膨的压力。但当前宏观环境看,通膨的压力是来自于缺工、供应链紧俏等问题,再加上拜登政府的大力推行财政刺激在那边推波助澜~

所以这一次的通膨是来自于实体经济上的供需失衡问题,并不是金融市场过度投机、企业超额投资等问题,我认为 Fed 在这次的通膨问题上,能做得空间非常有限。

这裡将产生一个不确定性的较大风险,就是 Fed 只能靠货币紧缩去压通膨预期,但实体经济的根本性通膨问题,还是没有获得解决。变成最终 Fed 只能再用更剧烈的紧缩政策,去引导通膨预期走低后,尝试来压低实际通膨率,所以这裡将让 Fed 的紧缩路径,存在著较大不确定性。

比较好的处理方式,应该是直接去解决实体经济上的缺工和供应链/例如我之前提到的塞港问题,让实际通膨率自己走低、而不是靠 Fed 挤压通膨预期之后去引导。

谁可以去把坐在白宫裡疑似患有阿兹海默的白髮老头一巴掌打醒...还我特~


结论:我个人认为 Fed 今年将加息四次,不至于加息五次,而加息四次之预期,相信市场应该已经定价;至于缩表,相信市场尚未定价,估计将落在 2022 下半年,最快可能是 6 月。

如果 Fed 今年加息五次,我会感到非常意外,因为这意味著 Fed 很可能在 2023 年底、2024 年初,就因为美国经济放缓太快而需要降息,Fed 这波操作就会变得非常韭。

最后说说股市的想法目前 Nasdaq 已经插水一段时日,抑制通胀是当务之急,而股市所谓修正才多久已出现V转。对通胀而言意义不大,修正数月才可能有帮助~所以我之前一直描述为“恐慌”。因此对白髮老头而言,怎麽做才有利于中期选举就很清晰了。

最好还是坚持认为市场或已定价加息四次之预期,但缩表预期则是尚未定价的观点。

配置上美股我倾向持有科技权值股,一些 Megacap 的估值我认为合理、前景确定性较高,而这样也可以让你的收益贴著 QQQ 走。

考虑到一堆成长股腰斩,我也愿意加仓接刀成长股,但建议佔据投资组合的比例,或许不要超过 15%,如果选股功力不错,这裡就会开始让你的收益拉开与 QQQ 之类的差距。

最后,我相信人人都会想在市场下跌的环境裡接刀,接刀不是不行,但若接刀失败,斩缆我建议速度要快,我个人不考虑价投的话一次斩缆的比例都是 50% 以上。




  

相关话题

  【校招面试】关于Typescript和ES6的对比? 
  江湖上流传着哪些关于R大RednaxelaFX的黑暗传说? 
  客户端 POST 错误,服务端应该回 200 还是 400? 
  有哪些效果拔群的 WebAssembly 应用? 
  对编程感兴趣的程序员是否都对电路、单片机也怀有浓厚的兴趣? 
  项目组里的代码审查员要我把代码写的很啰嗦,怎么办? 
  为什么做 Java 开发的公司需要那么多程序员? 
  既然有 HTTP 请求,为什么还要用 RPC 调用? 
  如何评价阿当的文章《当我说前端基础时,我在说什么》? 
  如何快速打好Java基础? 

前一个讨论
新药为什么卖那么贵?为什么不能薄利多销?
下一个讨论
Mac 外接显示器选择 Dell U2720QM 还是 LG Ultrafine 4K ?





© 2024-11-08 - tinynew.org. All Rights Reserved.
© 2024-11-08 - tinynew.org. 保留所有权利