Introduction à la standardisation des valeurs de retour de l'API (exemple de code)

Ce que cet article vous apporte est une introduction à la standardisation des valeurs de retour de l'API (exemples de code). Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer.

Standardisation de la valeur de retour de l'API

Par exemple,

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

encapsule l'objet de retour

L'objet est encapsulé sous base.util.ResponseUtils type et la valeur de retour Il s'agit d'un objet ResponseEntity standard. Le corps de retour
est encapsulé deux fois et se compose principalement du statut, du message et des données. Les méthodes de retour sont ok et okMessage. pas besoin d'un objet, vous pouvez choisir d'utiliser okMessage. Sinon, utilisez la méthode ok.

Objet de retour encapsulé :

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

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

httpError et notre httpError encapsulé

Il existe de nombreux types d'erreurs http, qui peuvent essentiellement être définies sous forme de code entre 400 et 500 Parmi eux, si le problème du paramètre client est 400-mauvaise demande, s'il n'y a pas d'authentification, ce sera 401-Non autorisé, s'il y a une authentification mais pas d'autorisation correspondante, ce sera 403-Interdit, si la ressource

demandée est introuvable, ce sera 404-Not Found, la méthode de requête. L'erreur (la méthode est post, vous avez utilisé get pour lancer la requête) est 405- Method Not Allowed, etc.

Utilisez le code d'état de réponse http standard

  @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));
  
   }

Résultat de la réponse

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

Utilisez notre code d'état encapsulé

  @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());
  
    }

Résultat de la réponse

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 = []

Comme vous pouvez le voir dans le résultat de la réponse ci-dessus, le code http de la requête que nous avons encapsulé est toujours 200, mais le code d'état de l'erreur de requête 400 est écrit dans Dans l'objet body

, cette méthode est actuellement utilisée plus souvent. Certaines interfaces tierces utilisent cette méthode et stipuleront les spécifications de réponse correspondantes.

Résumé

En fait, il n'y a aucun problème avec les deux corps de réponse. L'essentiel est de déterminer les règles entre développeurs et de ne pas utiliser les deux dans le projet !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!