@coderxy 是的，主要是成本，不然单条好处理多了 ，合并后还得拆结果，对不同来源的内容做后续动作，动作还不统一。就看成本与麻烦度的比例怎么样

@flyqie 赞同,看场景.

@AquanllR rest 是非常简洁,聚合强

@YuJianrong 好早啊,莫非在看 ti?😅 一看你就是 graphql 的受益者,当时一看到 graphql 的统一入口就惊呆了,心想这得多麻烦,全放到一个入口路由.不过他的自由查询还是很喜欢的.

@impaul put 也是用的 post body 传输方式,delete 用的 url 传值方式.😄 没用过 php,猜想应该也能用$_GET 和$_POST 获取

@thinkershare 非常谢谢,我再去深入了解下 rest 起源. 和名字挂边的最麻烦了😄

@dddd1919 谢谢指出,短短几句比看几篇博文用处更大. 刚又重翻了一篇 rest 看了下, 更感觉这个 rest 像分了类的 graphql. 如果是复杂的语义,只要对参数下手就行了

@zidian 之前都是用的似 rpc 方式,感觉换成 rest,像改变行为习惯一样. 没弄好,是会弄得一团糟.😂

@thinkershare 看到的许多博文,大部分都是根据 rest 方式做的分析.所以很想知道这种方式的优势. 如果 api 是面向的还有 app,小程序之类的,也适合 RESTful API 风格吗.

@javaisthebest 这个又到了比写代码还花时间的时候了,我应该把他放在哪合适.我应该叫他什么名字.

@caisanli /content/create 与/api/content/create 的区分 谢谢提醒

@xiang0818 是的,只是一个路径风格而已,到了服务器都是一样的. 幂等是要注意的,网络是不能相信的😆

@gongquanlin 兄弟,后面有升级吗. 现在跑得正常吗. 准备三台 2 核 4G,估计也好不到哪去,我是本地用的装的虚拟机 4 核 6G,两台 2 核 4G.

@wzw t6 应该这种适合做秒杀活动之类的吧. 当然正常用应该也能用吧.我只是看了官方适应场景.😁

@owen800q 线上 qps 没有实战过.这想弄个服务器跑先起来,前期达不到 1WQPS 的,看业务再升级的🤣. 你有没有建议的方案

@gongquanlin 4c8g 都很吃力吗. 你是一台还是几台 4c8g. 我还想三台 2c4g😂,看来这个想法实际操作有点悬呀

@GopherDaily 这说的这个方法不错.因为大多服务都是只跑下业务,数据都保存在其它地方.暂时还不要这么复杂,先跑起来就行了,这个可以后面考虑.谢谢你的方案.后面应该用得上.

@opengps 注册过了,之前都是买的单台. 还能注册个新号吗.哈哈.

@GopherDaily 刚看了下抢占实例,这个说是会被释放掉. slb,k8s 我去了解下.