你把那个禁止解析的参数加上就行吧。重定向到 null 肯定不起作用的

你这个工具是用在什么场合的啊，总感觉好危险

和公司商量商量呗，把公司应当缴纳的部分打个折现当奖金发呗，毕竟他就是交了于打工者其实没太大好处。（就目前的形势看

1 ，HTTP 状态码要用起来，至少出错时不许返回 200

github pages 可以当作静态内容托管用，想干啥都行（（

Pause 键起作用吗

@taobibi 发现了，只要 API 是正常的，大不了把那个无效 credential 的提示拿掉就完了

贴出操作用的 sql 呗

@lesismal 这就是不同的团队自己的选择了，你要把 HTTP 当应用层协议用，那就严格遵守 RESTful ；你要把 HTTP 当应用层协议的承载者用，那就意味着整个生态里，从头到尾所有的问题都需要自己解决。

@TossPig HaHa ，其实我一直想尝试下 JSONRPC over Websocket 的，但迫于这东西不管是穿 CDN 还是生态和缓存都有缺点

@lesismal 抱歉，这个是我看串了，你没说这个省资源，你说这个省心智负担。
我倒是觉得复杂度是不会降低的，只是在不同的形式间转换，现在流行的 RESTful 风格借助 HTTP 动词表达的语义，你用 RPC 风格一样要 CreateXxx UpdateXxx 。只是前者和 HTTP 结合的更好，也更容易被生态接受罢了。
权衡利弊，现阶段 PUT 都会出问题的系统基本上很少见了，个人认为大多数情况下拆掉这些过时的规则没什么问题。

@lesismal
把动词放到路由上基本都会遇到名词和动词混淆的问题，这个很恶心；
符合 RESTful 的设计更加便于理解，虽然私有 API 可以依靠完善的文档来弥补；
至于你说 POST200 更省资源这就有点扯了，都 application/json 你跟我说省资源？？？

甲方脑残，不过为了赚钱倒也可以迂回下，搞个 http over http 就好了。还可以宣传一波自带混淆，顺便多要点💰

@darknoll 你说的对

诶呀 go 可太工程化了，连泛型都没有，封装起来各种困难，然后索性不封装了，每个人自己弄一坨；标准库连 maxInt 都无，每个人自己写一坨……

发表点暴论：go 除了编译打包比 kt 快，语法规范比 kt 短，还有啥好处吗？这两个特点也都是放弃了大量特性才换来的…

还在使用旧版 swagger 啊

那个啥，说句中国互联网圈子政治不正确的话，我能推荐一下 kotlin 吗？虽然编译缓慢 gradle 更慢，但抱着 JVM 大腿生态问题不大，想尝鲜还有 coroutine，这东西某种意义上做的比 go 的 goroutine 好。更何况空安全啊等等各种漂亮的语法极大降低脑细胞阵亡概率。