关于某项目业务发展过程中的一些建设性想法

1、当下我们遇到的问题

1.1、Restful 形式的弊端愈发明显

在以前的开发中，我们讲究要完全遵循 Restful 的格式规范，比如：

• 请求使用 GET/POST/PUT/DELETE 等方式表达业务
• URI 不能出现动词，而是用名词（或复数）进行定义
• 响应使用 HTTP 状态码来表示结果
• 响应数据无需包装统一，即直接把结果放到 response 的 body 里面即可

但是随着时间的推移，且越来越多的生态集成进来，发现这种格式的缺点愈发明显，比如：

• 对于公众号或小程序，微信只要识别到响应状态码不是200，就认为请求错误，导致触发各种报警 / 误统计错误数据。
• 在 Skywalking（链路追踪平台）中同理，响应状态码不是200，就会认为请求错误。
• Restful 的部分路径命名确实存在好处，但是要求所有接口都遵守这个规范在实际的开发中难以实施（有时候仅靠名词命名实在无法表达）。
• Restful 的响应 body 数据结构无要求，可能是个 string、bool，或者是个 object，对于前端的某些自动化框架来说，很难处理，因为它不知道数据到底是什么类型。

1.2、Swagger 的部分局限性

Swagger 是一个流行的接口文档框架，能够帮助我们对接口、参数、响应结构、响应模型等生成详细的注释，同时也提供了一些开放的 api 供我们读取所有的接口信息，倘若有一天，我们需要用一个自动化工具去生成这些前端调用的代码，对于数据模型，如果加了 @ApiModel 注解，则接口返回的模型就是中文注释；反之不加，返回的才是模型类的名称。所以对于这一点，想实现自动化会无从下手。

2、未来我们要做的事

2.1、升级所有框架的版本

我们目前的微服务中依赖的各个框架版本都太老了，将来甚至会有不再维护的，因此我们要进行升级。当然，这个升级并不是在老服务的基础上改，而是要新建服务，待新服务稳定成熟后逐步的替换掉老服务。需要升级的框架比如：

• Spring & Cloud
• JDK（8 -> 17）
• Swagger（2.0 -> 3.0）
• Skywalking

2.2、尝试使用 Kotlin 写项目而非 Java

2.3、尝试使用自动化工具生成前端调用接口代码

3、小作业

每个人可以做一个新的 demo 服务，并尝试着解决以下的问题：

• 框架采用最新稳定版（结合第2点）
• 不用遵循 Restful ，不要使用原有公共 lib
• 新服务可以成功注册到 Eureka 并调用老服务
• 所有的业务错误返回200，在 body 中用 code 等进行描述
• 所有的响应数据用统一的数据结构封装，并且 Swagger 可以正确显示出 data 中的类型信息
• Skywalking 只有非业务错误才显示为错误，并且可以看到业务错误的 code
• 所有请求通过自定义 body 传值（方法参数看看能否实现用匿名类接收，防止定义过多的 req 类）
• 所有响应都是自定义的对象 res
• Service 接口细化，Controller 要发挥控制流程的作用

探讨图