Shulou(Shulou.com)06/01 Report--

This article introduces the relevant knowledge of "the method of unified format return of API interface". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Interface interaction

The front-end and the back-end interact. The front-end requests the URL path according to the agreement and passes in the relevant parameters. The back-end server receives the request, carries on the business processing, and returns the data to the front-end.

In view of the restful style of the URL path and the requirements of the common request headers for passing parameters (such as app_version,api_version,device, etc.), Lao Gu will not introduce it here. Friends can understand it for themselves, which is relatively simple.

How does the back-end server return the data to the front end?

Return format

When the backend returns to the frontend, we usually use the JSON style, which is defined as follows:

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

CODE status code

Code returns the status code. Generally, friends can add whatever they need when developing.

If the API wants to return a user permission exception, let's add a status code of 101. Next time, if we want to add a data parameter exception, add a status code of 102. Although this can satisfy the business as usual, the status code is too messy.

We should be able to refer to the status code returned by the HTTP request

The following are common HTTP status codes: 200-request successful 301-resources (web pages, etc.) are permanently transferred to other URL404-requested resources (web pages, etc.) do not have 500-internal server error

We can refer to such a design, and this benefit classifies the error type into a certain interval, and if the interval is not enough, it can be designed as four digits.

# 1000 '1999 interval indicates parameter error # 2000' 2999 interval indicates user error # 3000 '3999 indicates interface exception

In this way, after getting the return value, the front-end developer can know what is wrong according to the status code, and then quickly locate it according to the description of message-related information.

Message

This field is relatively easy to understand, that is, how to give a friendly prompt when an error occurs. A general design is designed in conjunction with code status codes, such as

And then define the status code in the enumeration.

The status code and information will correspond one by one, which is easier to maintain.

Data

Returns the data body in JSON format, and the JSON body varies according to different business.

We are 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, taking the order order as an example

We see that after getting the order object, we use the Result constructor to wrap the assignment and then return it. Friends have not found that the construction method of such packaging is not very troublesome, we can optimize it.

Aesthetic beautification

We can add static methods to the Result class, which can be understood at a glance

Then let's transform Controller.

The code is not more concise, but also beautiful.

Elegant optimization

Above we saw the addition of static methods to the Result class to make the business processing code concise. But have you guys noticed that there are a few questions:

1. The return of each method is an Result encapsulated object with no business meaning.

2. In the business code, we call Result.success when it is successful and call Result.failure with an exception error. Is it superfluous?

3. The above code determines whether id is null. In fact, we can use hibernate validate for verification, and there is no need to make a judgment in the method body.

The best way for us to return the real business object directly is not to change the way we used to do business.

This and our usual code is the same, very intuitive, directly return the order object, this is not perfect. So what is the implementation plan?

Realization scheme

Friends how to achieve is not a little bit of ideas, in this process, we need to do a few things

1. Define an annotation @ ResponseResult, indicating that the value returned by this API needs to be wrapped.

2. Intercept the request and determine whether the request needs to be annotated by @ ResponseResult

3. The core step is to implement the interfaces ResponseBodyAdvice and @ ControllerAdvice, determine whether the return value needs to be wrapped, and rewrite the return value of the Controller API if necessary.

Annotation class

Used to mark the return value of the method, whether it needs to be wrapped

Interceptor

To intercept a request, whether the value returned by this request needs to be wrapped is to parse the @ ResponseResult annotation at run time

The core idea of this code is to get this request, whether it needs to return a value wrapper, and set an attribute tag.

Rewrite the return body

The above code is to determine whether the return value wrapper is needed, and wrap it directly if necessary. Here we only deal with the normal successful packaging, what if the method reports an exception? Handling exceptions is also relatively simple, as long as you determine whether body is an exception class.

How to do the overall exception handling, space reasons, Lao Gu will not introduce here, as long as the train of thought is clear, self-transformation on the line.

Rewrite Controller

Add @ ResponseResult annotation to the controller class or method body, so it's ok, so it's simple. To return to the completion of the design idea, is not both concise and elegant.

Is there any other room for optimization in this scheme? of course there is. For example, every request needs to be reflected. Whether the method of the request needs to be wrapped can actually be used as a cache and does not need to be parsed every time. Of course, if you understand the overall idea, your friends can expand on this basis.

This is the end of the content of "the method returned by the unified format of the API interface". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.