Home  >  Article  >  Java  >  Introduction to standardization of api return values ​​(code example)

Introduction to standardization of api return values ​​(code example)

不言
不言forward
2019-03-08 16:26:253715browse

This article brings you an introduction to the standardization of API return values ​​(code examples). It has certain reference value. Friends in need can refer to it. I hope it will be helpful to you.

Standardization of api return value

For example

{"status":200,"message":"操作成功","data":"{\"id\":1,\"name\":\"张三\"}"}

Encapsulation return object

The object is encapsulated under the base.util.ResponseUtils type, and the return value is standard ResponseEntity object, the return body
is re-encapsulated, mainly composed of status, message and data. The return methods are ok and okMessage. If
really returns a message and does not need an object, you can choose to use okMessage, otherwise 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 types of http errors, which can basically be set as codes between 400 and 500 Yes, for example, if the client parameter problem is 400-bad request, if there is no authentication, it will be 401-Unauthorized, if there is authentication but no corresponding permission, it will be 403-Forbidden, if the requested
resource is not found, it will be 404-Not Found, and the request method is wrong ( The method is post (if you initiated the request using get), the result is 405- Method Not Allowed, etc.

  • Use 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));
  
   }

Result of 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("传入的参数非法!");
  }
  
  @Test
    public void getError() throws Exception {
      mockMvc
          .perform(
              get(LindDemo.GET_ERROR)
                  .accept(MediaType.APPLICATION_JSON_UTF8))
          .andExpect(status().isOk());
  
    }

Result of 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":"传入的参数非法!","data":{}}
    Forwarded URL = null
   Redirected URL = null
          Cookies = []

As you can see from the above response result, the request httpcode we encapsulated is still 200, but the request error 400 status code is written in the body
object. At present, this method is used more often. Some third-party interfaces use this method, and they will stipulate corresponding response specifications.

Summary

In fact, there is no problem with both response bodies. The key is to determine the rules between development and do not use both in the project!

The above is the detailed content of Introduction to standardization of api return values ​​(code example). For more information, please follow other related articles on the PHP Chinese website!

Statement:
This article is reproduced at:cnblogs.com. If there is any infringement, please contact admin@php.cn delete