百科问答小站 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% 以上。




  

相关话题

  创业公司选择 .NET 技术栈究竟比选 Java/Python 贵多少钱? 
  我发现设计模式一个很奇妙的情况,不知各位知友遇过没? 
  前端因为像素还原设计稿而离职,这是个别现象吗? 
  华为自研的「仓颉」编程语言,未来能取代java的地位吗? 
  为什么 JS 不能绕过后端代码直接调数据库,有哪些后端处理的逻辑,JS 不能写? 
  JAVA语言的优缺点是什么? 
  当年谷歌为什么不收购sun?而让Oracle买了去呢? 
  这段代码有没有正确释放堆栈空间? 
  Java中,有一个for循环调用网络api很耗时,请问如何减少耗时? 
  随着互联网的崛起,还有必要学习 C++ 吗?貌似 C++ 越来越难找工作了... 

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





© 2024-12-22 - tinynew.org. All Rights Reserved.
© 2024-12-22 - tinynew.org. 保留所有权利