Verificación de la interfaz de microservicio

Sanfeng suave Zhang Sanfeng

Plan de diseño de API

Las solicitudes HTTP se dividen en reglas de convención de URL y reglas de parámetros de solicitud reglas de URL: http: // {servidor} / {producto} / {versión} / {lógica} / {método}? {Query_string }　

1.servidor: es el nombre de dominio de servicio específico
2.producto: es el nombre del proyecto de la aplicación
3.versión: es el número de versión específico, que es conveniente para una futura expansión de funciones, se puede establecer provisionalmente como v1, v2
4.logic: es la división preliminar de la lógica comercial específica Por ejemplo, el método de administración de back-end, el método de solicitud en el lado de la aplicación 5. método
: Los
parámetros de solicitud específicos del método comercial específico están determinados por el método de método especificado, y todos se utilizan como la lista de parámetros HTTP GET / POST.

Reglas de respuesta http

El código de respuesta HTTP es 200 y el resultado devuelto tiene el formato de una cadena JSON: si el resultado de la respuesta es correcto, el resultado devuelto es el siguiente:


{　　
　　　　　　data : { // 请求数据，对象或数组均可
　　　　　　　　user_id: 123,
　　　　　　　　user_name: "zwz",
　　　　　　　　user_avatar_url: "http://www.abc.com/1.jpg"
　　　　　　　　...
　　　　　　},
　　　　　　msg : "done", // 请求状态描述，调试用
　　　　　　success : 1,
　　　　　　code" : 1001, // 业务自定义状态码
　　　　　　extra : { // 其他扩展的数据，字段、内容不定
　　　　　　　　type: 1,
　　　　　　　　desc: "签到成功！"
　　　　　　}
　　　　}

Si el resultado de la respuesta falla, se devuelve el siguiente resultado:


{
　　　　　　data : { // 请求数据，对象或数组均可
　　　　　　},
　　　　　　msg : "Internal Server Error", // 请求状态描述，调试用
　　　　　　success : 0,
　　　　　　code : 5001, // 业务自定义状态码
　　　　　　extra : {
　　　　　　}
　　　　}
}

código de error

Al diseñar la API, es mejor no vincular códigos de error comerciales con códigos de estado HTTP y redefinir un conjunto de códigos de error comerciales para distinguir los códigos de estado HTTP. Es mejor tener un conjunto de especificaciones para la definición de códigos de estado, similar a los códigos de estado HTTP, que pueden clasificarse simplemente de acuerdo con servicios relacionados con el usuario, relacionados con la autorización y varios.


// Code 业务自定义状态码定义示例
　　　　// 授权相关
　　　　1001: 无权限访问
　　　　1002: access_token过期
　　　　1003: unique_token无效
　　　　...

　　　　// 用户相关
　　　　2001: 未登录
　　　　2002: 用户信息错误
　　　　2003: 用户不存在

　　　　// 业务相关
　　　　3001: 业务XXX
　　　　3002: 业务XXX

　　　　// 系统异常
　　　　5001：Internal Server Error

Verificación de parámetros de solicitud de primavera

La verificación de datos admitida por SpringMVC es el estándar JSR303, que se verifica marcando @NotNull, @Max, etc. en las propiedades del bean. JSR303 proporciona muchas interfaces de anotación, y SpringMVC usa hibernate para estas verificaciones, por lo que necesitamos agregar un paquete de validación de hibernate: el marco ha proporcionado la verificación de la siguiente manera:


@Null 被注释的元素必须为 null
@NotNull 被注释的元素必须不为 null,不能为 null , 可以为 ""
@AssertTrue 被注释的元素必须为 true
@AssertFalse 被注释的元素必须为 false
@Min(value) 被注释的元素必须是一个数字，其值必须大于等于指定的最小值
@Max(value) 被注释的元素必须是一个数字，其值必须小于等于指定的最大值
@DecimalMin(value) 被注释的元素必须是一个数字，其值必须大于等于指定的最小值
@DecimalMax(value) 被注释的元素必须是一个数字，其值必须小于等于指定的最大值
@Size(max=, min=) 验证对象（Array,Collection,Map,String）长度是否在给定的范围之内
@Digits (integer, fraction) 被注释的元素必须是一个数字，其值必须在可接受的范围内
@Past 被注释的元素必须是一个过去的日期
@Future 被注释的元素必须是一个将来的日期
@Pattern(regex=,flag=) 被注释的元素必须符合指定的正则表达式

Hibernate Validator提供的校验注解：
@NotBlank(message =) 只能作用在String上，不能为null，而且调用trim()后，长度必须大于0
@Email 被注释的元素必须是电子邮箱地址
@Length(min=,max=) 被注释的字符串的大小必须在指定的范围内
@NotEmpty 被注释的字符串的必须非空，不能为 null、"",可以为 " "
@Range(min=,max=,message=) 被注释的元素必须在合适的范围内

para resumir

Por supuesto, depender únicamente de la verificación proporcionada por el marco no puede cumplir con el negocio cambiante en tiempo real, por lo que necesita escribir algunas reglas de verificación personalizadas basadas en el negocio. Por supuesto, esto es relativamente simple.