Source: Lao Gu chat technology

preface

In today’s mobile Internet, distributed and microservices are prevalent, most of the projects now adopt the microservice framework and the way of front and back end separation. The general architecture of the general system is as follows:

The interface interaction

The front end and the back end interact. The front end requests the URL path according to the convention and passes in relevant parameters. The back end server receives the request, processes services and returns data to the front end. In view of the restful style URL path, and to meet the requirements of the public request header incoming parameters (such as: appversion, apiversion, device, etc.), will not covered here, pay attention to introduce the backend server how to realize the data back to the front

Return format The back end returns to the front end. We generally use JSON body mode, which is defined as follows:

{# Return status code:integer, # return information description message:string, # return value data:object}Copy the code

CODE status CODE

Code returns the status code, which is used to add whatever is needed during development. If the interface wants to return a user permission exception, we add a status code of 101, and the next time we add a data parameter exception, we add a status code of 102. The following is a common HTTP status code: 200 — Request successful 301 — resource (web page, etc.) permanently transferred to another URL404 — Requested resource (web page, etc.) does not exist 500 — internal server error

We can refer to this design, and the benefit of this is to classify the error type into some interval, and if the interval is not enough, we can design it into four digits.

The range from 1000 to 1999 indicates that the parameter is incorrect

The range from 2000 to 2999 indicates a user error

The range from 3000 to 3999 indicates that the interface is abnormal

In this way, the front-end developer, after receiving the return value, can know what the error is based on the status code, and can quickly locate the error based on the description of the message related information.

Message

This field is relatively simple to understand, is the error occurs, how to friendly prompt. The general design is designed with the code status code, such asDefine the status code in the enumerationThe status code and the information will correspond one to one, which is easier to maintain.

Data

Returns the data body in JSON format, which varies according to the business. We’re going to design a return body class Result

Control layer Controller

We will process the business request at the Controller layer and return it to the front end, for example the Order orderWe see that after we get the Order object, we wrap the assignment with the Result constructor and then return it. Do you find that the constructor wrapper is not troublesome, we can optimize it.

Beautiful and optimization

We can add static methods to the Result class, just to make senseSo let’s change the ControllerThe code is not more concise, also beautiful.

Elegant optimization

We saw above that static methods were added to the Result class, making the business processing code simpler. Each method returns a Result encapsulated object, which has no business meaning. 2. In business code, result. success is called when success occurs, and result.failure is called when exception occurs. Hibernate Validate = null; hibernate validate = null; hibernate Validate = null; hibernate Validate = null Our best approach is to return the real business object directly, preferably without changing the previous business approach, as shown belowThis is the same as our usual code, very intuitive, directly return the order object, isn’t it perfect. So what’s the implementation?

Implementation scheme

(ResponseResult) (ResponseResult) (ResponseResult) (ResponseResult) (ResponseResult) The key step is to implement ResponseBodyAdvice and @controllerAdvice, wrap the return value, and override the return value of the Controller interface if necessary. The annotation class is used to mark the return value of a method and whether it needs to be wrapped

The interceptor

Intercepting the request, whether the value returned by the request needs to be wrapped, is essentially parsing the @responseresult annotation at runtimeThe core idea of this code is to get this request, whether you need to return the value wrapper, set an attribute tag.

Overwrite return body

The code above is to determine whether return value wrapping is required, and if so, to wrap it directly. Here we only deal with normal successful wrapping, what if the method body reports an exception? Handling exceptions is also easy, as long as you determine whether the body is an exception class.How to do global exception processing, space reasons, old care here will not be introduced, as long as the idea is clear, on the line of their own transformation.

Rewrite the Controller

Put an @responseresult annotation on your controller class or on your method body, and you’re done. Simple. The design idea that returns to this is completed, is not concise again, elegant again.

conclusion

Is there room for further optimization in this scheme? Of course there is. For example, each request needs to be reflected, whether the method to get the request needs to be wrapped, in fact, can do a cache, do not need to be resolved every time. Of course, the overall idea of understanding, partners can expand on this basis. Thanks!!