La interfaz de la especificación del código Java devuelve un formato unificado (clase de enumeración)

La estructura general del sistema es la siguiente:

imagen

Lo que hay que explicar es que algunos socios pequeños responderán que esta arquitectura es demasiado simple y demasiado baja: no hay puertas de enlace, cachés ni middleware de mensajes. Debido a que este artículo habla principalmente de la interfaz API, nos centraremos en este punto.

interacción de interfaz

El front-end y el back-end interactúan. El front-end solicita la ruta URL de acuerdo con el acuerdo y pasa los parámetros relevantes. El servidor back-end recibe la solicitud, realiza el procesamiento comercial y devuelve datos al front-end. .

Para el estilo tranquilo de la ruta URL y los requisitos de los encabezados de solicitud pública de los parámetros entrantes (como: app_version, api_version, dispositivo, etc.), no los presentaré aquí. Los amigos pueden aprender por sí mismos y es relativamente simple.

¿Cómo devuelve el servidor backend datos al frontend?

formato de retorno

El backend regresa al frontend, generalmente usamos el cuerpo JSON, que se define de la siguiente manera:

 

{
  #返回状态码
  code:integer,
  #返回信息描述
  message:string,
  #返回值
  data:object
}

CÓDIGO código de estado

El código devuelve el código de estado. Generalmente, los amigos agregan lo que necesitan durante el desarrollo.

Si la interfaz quiere devolver una excepción de permiso de usuario, agreguemos un código de estado de 101. La próxima vez que necesitemos agregar una excepción de parámetro de datos, agregaremos un código de estado de 102. Aunque esto puede satisfacer el funcionamiento habitual, el código de estado es demasiado confuso.

Deberíamos poder hacer referencia al código de estado devuelto por la solicitud HTTP.

 

:下面是常见的HTTP状态码:
200 - 请求成功
301 - 资源(网页等)被永久转移到其它URL
404 - 请求的资源(网页等)不存在
500 - 内部服务器错误

imagen.gif

Podemos referirnos a un diseño de este tipo, que tiene la ventaja de clasificar los tipos de error en un rango determinado, si el rango no es suficiente, se puede diseñar con 4 dígitos.

 

#1000~1999 区间表示参数错误
#2000~2999 区间表示用户错误
#3000~3999 区间表示接口异常

De esta manera, después de obtener el valor de retorno, el desarrollador front-end puede conocer el error aproximado según el código de estado y luego localizarlo rápidamente según la información relacionada con el mensaje.

Mensaje

Este campo es relativamente sencillo de entender, es decir, cómo dar un aviso amigable cuando ocurre un error. El diseño general se diseña junto con el código de estado del código, como

imagen.png

Luego defina en la enumeración, el código de estado.

imagen

El código de estado y la información se corresponderán uno por uno, lo que es más fácil de mantener.

Datos

Devuelve el cuerpo de datos en formato JSON y diferentes cuerpos JSON según diferentes negocios.

Queremos diseñar una clase de cuerpo de retorno Resultado

imagen

Controlador de capa de control

Procesaremos solicitudes comerciales en la capa del controlador y las devolveremos al front-end, tomando el orden como ejemplo.

imagen.png

Vemos que después de obtener el objeto de pedido, usamos el constructor Result para ajustar y asignar valores, y luego regresar. Amigos, ¿han notado que el empaque del método de construcción no es muy problemático, podemos optimizarlo?

Embellecimiento

Podemos agregar métodos estáticos a la clase Resultado para comprenderlo de un vistazo.

imagen.png

Entonces transformemos el controlador.

 

imagen.png

¿Es el código más simple y hermoso?

optimización elegante

Arriba vimos que se agregó un método estático a la clase Resultado, lo que hace que el código de procesamiento comercial sea más conciso. Pero amigos, ¿han notado que hay varios problemas:

1. El retorno de cada método es un objeto de paquete de resultados, que no tiene significado comercial.

2. En el código comercial, llamamos a Result.success cuando tiene éxito y llamamos a Result.failure cuando hay una excepción. ¿Es redundante?

3. El código anterior juzga si la identificación es nula o no. De hecho, podemos usar validar para la verificación y no es necesario juzgar en el cuerpo del método.

Nuestra mejor manera es devolver directamente el objeto comercial real. Es mejor no cambiar el método comercial anterior, como se muestra en la siguiente figura.

imagen

Este es igual que nuestro código habitual, es muy intuitivo y devuelve el objeto de pedido directamente, ¿no es perfecto? ¿Cuál es el plan de implementación?

Plan de IMPLEMENTACION

Amigos, ¿tienen algunas ideas sobre cómo lograrlo? En este proceso, debemos hacer algunas cosas.

1. Personalice una anotación @ResponseResult, que indica que el valor devuelto por esta interfaz debe empaquetarse

2. Intercepte la solicitud y juzgue si es necesario anotar la solicitud con @ResponseResult

3. El paso principal es implementar las interfaces ResponseBodyAdvice y @ControllerAdvice, determinar si el valor de retorno debe empaquetarse y, si es necesario, reescribir el valor de retorno de la interfaz del Controlador.

clase de anotación

Se utiliza para marcar el valor de retorno del método, si es necesario envolverlo

imagen

interceptador

Intercepte la solicitud, si el valor devuelto por esta solicitud debe empaquetarse, de hecho, es para analizar la anotación @ResponseResult cuando se ejecuta

imagen

La idea central de este código es obtener la solicitud, si necesita envolver el valor de retorno y establecer un indicador de atributo.

reescribir el cuerpo del retorno

imagen

El código anterior sirve para juzgar si se necesita el paquete del valor de retorno y, si es necesario, envolverlo directamente. Aquí solo nos ocupamos del empaquetado normal exitoso, ¿qué pasa si el cuerpo del método informa una excepción? También es relativamente sencillo manejar excepciones, simplemente juzgue si el cuerpo es una clase de excepción.

imagen

Reescribir controlador

imagen

 

Agregue una anotación personalizada @ResponseResult en la clase del controlador o en el cuerpo del método, así que está bien, es fácil. La idea de diseño que aquí se devuelve está completa, ¿es simple y elegante?

¿Existe algún otro margen de optimización en esta solución? Por supuesto que sí. Por ejemplo: cada solicitud debe reflejarse, si el método para obtener la solicitud debe empaquetarse; de ​​hecho, se puede almacenar en caché y no es necesario analizarlo cada vez. Por supuesto, si comprende la idea general, puede ampliarla sobre esta base.

 

Supongo que te gusta

Origin blog.csdn.net/qq_41916378/article/details/109571578
Recomendado
Clasificación