正式工 A：哎，B，你手下的外包空吗？能借我用一下吗？
正式工 B：可以，你拿去用两天好了。

又不是所有的 http 请求一定要去往流里读写。
假设你遇到一个场景，只需要调用一下 http 接口，不需要关心结果返回，那你不去调 connect 你怎么连接？

人家说看不懂都只是调侃罢了，真以为学不会呢？
这么跟你说吧，大部分后端，入门一门新东西，大概搭建环境可能也就多点只占 30%左右。
然而前端这边，npm package.json 还算好装，接下去 webpack 和 babel 配置就跟噩梦一样。
好不容易花了大把时间研究文档终于搞出了一个脚手架来，这时候我想用一下类似 antd 之类的第三方 ui 类库，结果发现，要引入一个 ui 类库居然要大改 webpack 和 babel 相关配置。

够折腾

我觉得前端烦就烦在喜欢弄一堆工具。
比如上手 react 吧，新人就要去搞 webpack npm，step by step 先把环境搭起来。
这一步就可能栽坑。
上 google 搜索教程，可能是一两年前的，然后相关的类库、插件的 api 已经变的妈都不认识了。想搞个 hot-reload，结果弄出了一堆的相关配置，每一个看起来都完全不一样，一个个试过去结果全 tm 失败了。

弄好 webpack，然后还要再弄 babel，这个坑更多，配置参数一堆一堆的。

最后找了官方的 create-react-app，结果明明都是同样的 webpack、babel，为什么这玩意封装起来后看着完全不一样。

环境配置阶段就劝退了。

也难怪会有 webpack 配置工程师的调侃。

@binux 所以，不用 restful 就是走泥巴路哦？用 restful 就是拓宽道路走向更远的未来？
我可以研究的东西有好多好多，为什么要花时间在一种设计风格上争论个没完没了？
存粹一个设计风格取舍的问题也能扯到 35 岁。你独清？

真以为现在互联网项目是像以前传统软件开发一样一套代码可以流传个几十年呢？就现在中国互联网开发速度，一套代码能撑五年以上就已经很不错了。基本上转了 4、5 手面目全非，然后等着下一轮重构了。

而且现在架构风格都在往微服务架构方向转，在微服务架构方向下，那些代码解耦合、可扩展、维护性之类的工程方面优势也就没有那么重要。

@bnm965321
阿里云 OSS 这套 restful API 是完完全全照搬亚马逊而不是阿里云自己设计的。
亚马逊 S3 现在云存储服务的事实标准。各大云服务产商的云存储服务都实现 S3 api 的兼容。

楼主就一个小年轻，还有楼上扯什么不爱学习的，我可去 xxx 的吧。什么时候 api 设计风格变成了一种专业技能了？

restful 只是一种 api 设计风格，什么时候变成了强制规范了？有什么 PUT/DELETE 能完成而 POST 不能完成的东西么？
非要把 restful 当成圣经一样是不是傻？搞得自己弄个 restful 就高人一等一样。团队的约定是什么样的，那就好好去遵守行么？

后端遗留有很多历史代码，你这边自作主张加了 PUT/DELETE，可能后端需要做其他的调整，特别是 java 这种各种拦截器了，或者是运维网关上有禁了 PUT 之类方法的。

综上，2020 还 restful 至上的，有一个算一个傻 x。整个阿里巴巴 api 网关就用 post/get，撑起了整个亿级的微服务系统，你那点破流量的项目还在纠结 put 和 post，不觉得滑稽？

spring 在测试类上打上 @transactional 注解。
这样运行完测试方法会自动回滚数据，比 before after 清理资源方式更简单

有干货的记事本都能记
没干活的纠结笔记工具

因为 spring 注入的类都是通过 cglib 之类的字节码框架增强代理过的，经过反射之类的机制性能肯定会下降。
但是 200-300ms 就有点夸张了。
你确定不是其他地方有干扰。

Uncaught ReferenceError: jsyaml is not defined

我来总结一下，

整天嘴上挂着 restful 的基本都是那种刚毕业没几年充满了理想主义，然后在小公司混迹的，工作量太少吃饱了没事干整天把 restful 当成圣经一样供奉着。

小公司增删改查没多大复杂业务的，妄想几个 http code 来解决业务需求，脑子烧坏了把。

如果你有做过框架的话，你会体会到多态给你带来的好处。
在实际业务开发里，这种方式的编码带来的好处比较有限。
大部分其实也是大家约定俗成保留了这种方式。

@learnshare ant 团队（以及支付宝系列产品）是属于蚂蚁金服的，蚂蚁金服和阿里巴巴是两家相互独立的公司。
脑补也要依照基本法来。

阿里巴巴自己内部有 ice 框架。

自带 terminal ui 不好看