ServerResponse (Server Unified Response data Format)

Strictly speaking, ServerResponse should be grouped in the Common package. But I really like this thing. And it’s used so often that I can’t help but recommend it.

I would like to take this opportunity to make it clear that not all of the categories in this series are my original ones. They are all the ones I have seen in various projects. I feel very good and have accumulated them little by little. Of course, there are some tools I wrote in the back. The important thing is to learn, to learn from it, and even without these tools, we can write our own.

In this scenario, I really think anyone who has written interfaces needs this.

In fact, when I first touched the code, I saw the JSON returned by the big interface. JSON in addition to the necessary data, there are various state codes, state description, and so on, feel very impressive. Later I gradually understand that this thing is a must, you do not write to try to see if the big guy with you interaction will pat you into a meat pie.

Back end: Ah, this request from the front end, the database has no corresponding data ah. Return null.

Front-end: big brother, you return me a null, is not the interface problem ah?

Back end: The data you requested is not in the database.

Front end: Oh. I see.

Back end: Yikes, this request from the front end, the parameters are wrong (maybe the necessary parameters are empty or something). I’m going to return null.

Front end: eldest brother, you return me null, is the database has no corresponding data? But there should be data for this condition.

Back end: No, there is something wrong with the parameters you requested.

Front end: eldest brother, that you pour to I want to give feedback. Otherwise, I thought you had no data.

Back end: Ok. Let me see.

Back end: Hey, buddy. I came up with a good idea, I wrote a ResultVo, and it looks like this… %￥&￥…… .

Front end: Ok. I see.

Back end: Gee, this request from the front end does not have enough permissions. I’m going to return data=null&code=10. And then set it up on the constant scale.

Front-end: I just happened to notice that your code has been added by 10. What does that mean?

Back end: Ah. I forgot to tell you. Code =10 indicates insufficient permissions.

Front end: Then I need to provide specific instructions to the user for this situation.

Back end: This is inefficient. And there may be more complex and volatile situations in the future. I have to think of something.

Back end: Hey, buddy. I upgraded the old ResultVo and it looks like this… % & % &… .

Front end: This is nice, in many places I can display MSG directly. However, there is a problem, there are too many codes now. I traverse the judgment every time I process, and often I just need to determine if the response was successful.

Back end: I see. I have to work on it a little bit.

Back end: After consulting the big guy, I got a great solution. Also, I make small adjustments based on my business situation, and there’s nothing wrong with that.

Front end & Back End: We saw significant improvements in efficiency and, most importantly, code specifications (contracts).

Strictly speaking, ServerResponse should be grouped in the Common package. But I really like this thing. And it’s used so often that I can’t help but recommend it.

I would like to take this opportunity to make it clear that not all of the categories in this series are my original ones. They are all the ones I have seen in various projects. I feel very good and have accumulated them little by little. Of course, there are some tools I wrote in the back. The important thing is to learn, to learn from it, and even without these tools, we can write our own.

In this scenario, I really think anyone who has written interfaces needs this.

In fact, when I first touched the code, I saw the JSON returned by the big interface. JSON in addition to the necessary data, there are various state codes, state description, and so on, feel very impressive. Later I gradually understand that this thing is a must, you do not write to try to see if the big guy with you interaction will pat you into a meat pie.

Back end: Ah, this request from the front end, the database has no corresponding data ah. Return null.

Front-end: big brother, you return me a null, is not the interface problem ah?

Back end: The data you requested is not in the database.

Front end: Oh. I see.

Back end: Yikes, this request from the front end, the parameters are wrong (maybe the necessary parameters are empty or something). I’m going to return null.

Front end: eldest brother, you return me null, is the database has no corresponding data? But there should be data for this condition.

Back end: No, there is something wrong with the parameters you requested.

Front end: eldest brother, that you pour to I want to give feedback. Otherwise, I thought you had no data.

Back end: Ok. Let me see.

Back end: Hey, buddy. I came up with a good idea, I wrote a ResultVo, and it looks like this… %￥&￥…… .

Front end: Ok. I see.

Back end: Gee, this request from the front end does not have enough permissions. I’m going to return data=null&code=10. And then set it up on the constant scale.

Front-end: I just happened to notice that your code has been added by 10. What does that mean?

Back end: Ah. I forgot to tell you. Code =10 indicates insufficient permissions.

Front end: Then I need to provide specific instructions to the user for this situation.

Back end: This is inefficient. And there may be more complex and volatile situations in the future. I have to think of something.

Back end: Hey, buddy. I upgraded the old ResultVo and it looks like this… % & % &… .

Front end: This is nice, in many places I can display MSG directly. However, there is a problem, there are too many codes now. I traverse the judgment every time I process, and often I just need to determine if the response was successful.

Back end: I see. I have to work on it a little bit.

Back end: After consulting the big guy, I got a great solution. Also, I make small adjustments based on my business situation, and there’s nothing wrong with that.

Front end & Back End: We saw significant improvements in efficiency and, most importantly, code specifications (contracts).