一种接口统一请求响应方法及装置与流程

1.本发明涉及springboot框架技术领域，具体提供一种接口统一请求响应方法及装置。


背景技术：

2.随着软件系统业务需求的不断增加，软件开发架构也随之演变，从单体式架构到分布式架构，再到微服务架构。同时系统前后端分离，交由不同的工程师开发，前后端传递数据时常常需要约定好统一的数据请求响应结构体。这导致后端工程师总是要在接口响应数据外再包裹一层响应体，对系统异常需要逐个捕获封装，处理业务异常时为了返回统一格式的数据更是大废周章。


技术实现要素：

3.本发明是针对上述现有技术的不足，提供一种实用性强的接口统一请求响应方法。
4.本发明进一步的技术任务是提供一种设计合理，安全适用的接口统一请求响应装置。
5.本发明解决其技术问题所采用的技术方案是：
6.一种接口统一请求响应方法，首先要在pom文件中引入包的坐标，等待引入完成后，在服务模块的主启动类的@springbootapplication注解处确认接口增强类controllerexceptionadvice和controllerresponseadvice被扫描到，如果没有被扫描到，在@springbootapplication注解的包扫描参数中添加工具包的groupid，所述工具包使用springboot2.2.2release版开发框架，工具包包括了advice、annotation、code、entities和exception五大部分。
7.进一步的，所述advice结合@restcontrolleradvice注解对接口进行增强处理，增强接口responsebody的响应数据，将业务数据自动封装成统一返回对象commonresult，同时对于已手工封装的接口和添加有@nocontrollerresponseadvice注解的接口不进行响应增强，提高该工具包的可用性。
8.进一步的，advice另外增强接口的异常处理，对所有的系统异常错误信息都封装到commonresult中；对参数校验异常bindexception进行特殊处理，返回前后端人员约定好的状态信息；对运行时业务异常apiexception返回自定义的提示信息。
9.进一步的，所述annotation定义了工具包中使用的@nocontrollerresponseadvice注解。
10.进一步的，所述code定义了前后端约定好的状态信息的接口和多种实现，接口statuscode约定了状态信息的结构，通过枚举类实现接口，一个是resultcode用于对接口请求、参数校验、自动封装的状态返回，前端通过状态信息根据对应的状态码判断请求是否成功；
11.另一个实现是apicode，用于对业务异常的状态返回。
12.进一步的，所述entities定义工具包中使用的实体类，commonresult的定义为约定前后端数据请求响应的统一结构，包括状态码、状态信息和业务数据。
13.进一步的，所述exception定义业务异常apiexception，供增强接口处理发生的业务异常使用；
14.apiexception继承了runtimeexception，使用时自主选择异常业务状态码，或只填充需要抛出的异常信息，默认返回app_error“业务异常”状态码。
15.进一步的，使用时，调用service层的业务函数，直接进行返回，工具包自动封装到commentresult中。
16.一种接口统一请求响应装置，包括：至少一个存储器和至少一个处理器；
17.所述至少一个存储器，用于存储机器可读程序；
18.所述至少一个处理器，用于调用所述机器可读程序，执行一种接口统一请求响应方法。
19.本发明的一种接口统一请求响应方法及装置和现有技术相比，具有以下突出的有益效果：
20.本发明降低了业务数据和数据响应的耦合度，提高了开发人员的效率，更专注于业务逻辑开发。减轻了前后端人员的对接难度，进一步提高了系统的一致性和规范性，不论业务数据信息还是异常信息都可以友好的传递到前台，节省了调试维护时间。
附图说明
21.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
22.附图1是一种接口统一请求响应方法的流程示意图。
具体实施方式
23.为了使本技术领域的人员更好的理解本发明的方案，下面结合具体的实施方式对本发明作进一步的详细说明。显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例都属于本发明保护的范围。
24.下面给出一个最佳实施例：
25.如图1所示，本实施例中的一种接口统一请求响应方法，首先要在pom文件中引入包的坐标，等待引入完成后，在服务模块的主启动类的@springbootapplication注解处确认接口增强类controllerexceptionadvice和controllerresponseadvice被扫描到，如果没有被扫描到，在@springbootapplication注解的包扫描参数中添加工具包的groupid，所述工具包使用springboot2.2.2release版开发框架，工具包包括了advice、annotation、code、entities和exception五大部分。
26.其中，advice：该部分基于aop思想，结合@restcontrolleradvice注解对接口进行
增强处理。一方面增强接口responsebody的响应数据，将业务数据自动封装成统一返回对象commonresult，同时对于已手工封装的接口和添加有@nocontrollerresponseadvice注解的接口不进行响应增强，提高该工具包的可用性。例如一些健康监测接口，只需要它返回一个字符串“healthy”，这时在该接口方法上添加@nocontrollerresponseadvice注解就不会干扰到其正常调用。另一方面增强接口的异常处理，对所有的系统异常错误信息都封装到commonresult中；对参数校验异常bindexception进行特殊处理，返回前后端人员约定好的状态信息；对运行时业务异常apiexception返回自定义的提示信息。
27.annontation定义了工具包中使用的@nocontrollerresponseadvice注解。
28.code：该部分定义了前后端约定好的状态信息的接口和多种实现。接口statuscode约定了状态信息的结构，通过枚举类实现该接口，一个是resultcode，用于对接口请求、参数校验、自动封装的状态返回，前端通过此状态信息就可以根据对应的状态码判断请求是否成功。另一个实现是apicode，用于对业务异常的状态返回，比如价格异常、响应包异常、数据库插入异常等。
29.entities：该部分定义了工具包中使用的实体类，commonresult在此处定义，它约定了前后端数据请求响应的统一结构，包括状态码、状态信息、业务数据。commonresult设置了6个构造函数，如下表所示：
[0030][0031][0032]
exception：该部分定义了业务异常apiexception，供增强接口处理发生的业务异常使用。apiexception继承了runtimeexception，使用时可以自主选择异常业务状态码，也可以只填充需要抛出的异常信息，默认返回app_error“业务异常”状态码。
[0033]
开发者使用时，调用service层的业务函数，直接进行返回，工具包自动封装到
commentresult中。例如查询订单信息接口，服务层返回了一个payment对象，直接return该payment对象即可，如果得到的是一个空对象，可以直接抛出一个业务异常，附上“订单号不存在”的友好提示。当接口执行过程中产生系统异常时，比如出现“除数为0”的异常，程序会报“/by zero”的异常信息，工具包会将该异常信息封装到commentresult中，返回给前端，当发生“除数为0”的系统异常时，前端把“/by zero”以弹窗的形式提示给开发人员，快速定位异常。
[0034]
基于上述方法，本实施例中的一种接口统一请求响应装置，包括：至少一个存储器和至少一个处理器；
[0035]
所述至少一个存储器，用于存储机器可读程序；
[0036]
所述至少一个处理器，用于调用所述机器可读程序，执行一种接口统一请求响应方法。
[0037]
上述具体的实施方式仅是本发明具体的个案，本发明的专利保护范围包括但不限于上述具体的实施方式，任何符合本发明的一种接口统一请求响应方法及装置的且任何所述技术领域普通技术人员对其做出的适当变化或者替换，皆应落入本发明的专利保护范围。
[0038]
尽管已经示出和描述了本发明的实施例，对于本领域的普通技术人员而言，可以理解在不脱离本发明的原理和精神的情况下可以对这些实施例进行多种变化、修改、替换和变型，本发明的范围由所附权利要求及其等同物限定。