Standardized Explanation of java api Return Value

Normalization of api Return Values

For example

{"status":200,"message":" Operation successful ","data":"{\"id\":1,\"name\":\" Zhang 3\"}"}

Encapsulate the returned object

Object is encapsulated under base. util. ResponseUtils type. The return value is standard ResponseEntity object. The return body is encapsulated twice status , messsage And data Composition, return methods are ok and okMessage. If you really return messages, you don't need objects, and you can choose to use them okMessage On the contrary, use ok Method.

Encapsulated return object:

 @Builder
 @Getter
 @NoArgsConstructor
 @AllArgsConstructor
 static class ResponseBody {

 private int status;
 private String message;
 private Object data;
 }

httpError and our encapsulated httpError

There are many kinds of http error, which can be basically defined as code between 400 and 500, like the client parameter problem is 400- bad request , and no certification is 401-Unauthorized Authenticated but without corresponding permissions is 403-Forbidden , requested
Resources are not found 404-Not Found Wrong request mode (method is post, you used get to initiate the request) 405- Method Not Allowed Wait.

Use the standard http response status code

 @GetMapping(GET_HTTP_ERROR)
 ResponseEntity<?> getHttpError() throws IOException {
 return ResponseEntity.badRequest().build();
 }
 @Test
 public void getHttpError() throws Exception {
  mockMvc
   .perform(
    get(LindDemo.GET_HTTP_ERROR)
     .accept(MediaType.APPLICATION_JSON_UTF8))
   .andExpect(status().is(400));
 
 }

The result of the response

MockHttpServletResponse:
   Status = 400
 Error message = null
   Headers = {}
  Content type = null
    Body = 
 Forwarded URL = null
 Redirected URL = null
   Cookies = []

Use our encapsulated status status code

 @GetMapping(GET_ERROR)
 ResponseEntity<?> getError() throws IOException {
 return ResponseUtils.badRequest(" The parameter passed in is illegal! ");
 }
 
 @Test
 public void getError() throws Exception {
  mockMvc
   .perform(
    get(LindDemo.GET_ERROR)
     .accept(MediaType.APPLICATION_JSON_UTF8))
   .andExpect(status().isOk());
 
 }

The result of the response

MockHttpServletResponse:
   Status = 200
 Error message = null
   Headers = {Content-Type=[application/json;charset=UTF-8]}
  Content type = application/json;charset=UTF-8
    Body = {"status":400,"message":" The parameter passed in is illegal! ","data":{}}
 Forwarded URL = null
 Redirected URL = null
   Cookies = []

From the above response results, we can see that the request httpcode is still 200, but the request error 400 status code is written in body
Object, the current use of this method is more, such as some of the third-party interfaces are used in this way, they will specify the corresponding response specifications.

Summarize

In fact, there is no problem with either response body, the key is to determine the rules between development, not to use both in the project!