其实相比于 RESTFull ，post+struct body 方式的路由也好、参数也好（甚至路由也放到 body struct 字段里，但是比如 nginx 日志之类的不友好、需要插件解码再日志才行），更统一，比如参数，不需要再去 header 的 kv 、form 或者 body 各种地方取，而且写法上，以 go 语言为例，一个 ctx.Bind(&args)，后续的参数就都可以是结构体字段，干净得很。有的人喜欢省事用 map 类型，然后取到 interface{}再解析，这种不推荐，理由跟强弱类型语言做工程的优劣类似，而且项目足够规范，就应该协议制定阶段定好类型，然后就都很规范干净。当然，不同语言，强类型、弱类型、还有 java 这种带注解的，对于这种方式参数使用的便利未必一样。但至少在 go 和其他一些语言领域，或者从设计、获取参数来源上，确实是简便了一些的。而且 RESTFull 多种方法相关的，我前面说路由命名一样能解决，RPC 也一样的道理，如果命名解决不了，那 RESTFul 也未必能解决的了、只是增加一个维度的复杂度而已。
一些传统业务，社区已经既有很多成熟的解决方案，比如企业级、电商、管理后台系列、金融相关的很多，还有一些语言优势领域比如 PHP ROR 各种擅长的中小项目领域，这些成型的成熟方案改造使用 post+struct body 没什么必要，或者像楼主这种，公司已经形成了比较统一的项目规范，改个另类出来反倒增加团队负担，也没必要。 但是近年的一些新项目，尤其 go 语言这种，因为没有历史包袱，主流的框架以及相对中等以上水平的团队，很多都会选择 post+struct body 的方式。所以之前其他楼一些同学说我应该跟上时代，我都觉得他们有点说反了，可能他们才是没跟上时代吧 :joy:
另外关于 websocket ，我这有个 go 的 rpc 框架，支持 websocket 作为 transport 层，而且不只是 rpc ，可以服务端主动发消息给客户端，可以避免线头阻塞，可以乱序响应，而且能够支持更多业务场景比如推送、IM 、游戏等等： github.com/lesismal/arpc