Einführung in die Standardisierung von API-Rückgabewerten (Codebeispiel)

Dieser Artikel bietet Ihnen eine Einführung in die Standardisierung von API-Rückgabewerten (Codebeispiele). Ich hoffe, er wird Ihnen als Referenz dienen.

Standardisierung des API-Rückgabewerts

Zum Beispiel kapselt

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

das Rückgabeobjekt

Das Objekt ist unter dem Typ base.util.ResponseUtils gekapselt, und der Rückgabewert ist ein Standard-ResponseEntity-Objekt, der Rückgabetext
wird neu gekapselt und besteht hauptsächlich aus Status, Nachricht und Daten. Die Rückgabemethoden sind ok und okMessage Wenn
wirklich eine Nachricht zurückgibt Wenn Sie ein Objekt verwenden, können Sie okMessage verwenden. Andernfalls verwenden Sie die OK-Methode.

Gekapseltes Rückgabeobjekt:

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

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

httpError und unser gekapselter httpError

Es gibt viele Arten von http-Fehlern, die grundsätzlich als Code zwischen 400 und 500 festgelegt werden können. Ja, z Wenn das Client-Parameterproblem beispielsweise eine 400-schlechte Anfrage ist, wenn keine Authentifizierung vorliegt, ist es 401-Unautorisiert, wenn eine Authentifizierung, aber keine entsprechende Berechtigung vorhanden ist, ist es 403-Verboten, wenn die angeforderte
-Ressource vorhanden ist nicht gefunden, wird es 404-Not Found sein und die Anforderungsmethode ist falsch (Die Methode ist post (wenn Sie die Anforderung mit get initiiert haben), das Ergebnis ist 405-Methode nicht zulässig usw.

• Verwenden Sie den Standard-HTTP-Antwortstatuscode

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

Das Ergebnis der Antwort

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

• Verwenden Sie unseren gekapselten Statuscode

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

Antwortergebnis

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

Wie Sie dem obigen Antwortergebnis entnehmen können, ist der von uns gekapselte Anforderungs-HTTP-Code immer noch 200, aber der Statuscode des Anforderungsfehlers 400 wird in den Textkörper geschrieben
Derzeit wird diese Methode häufiger verwendet. Einige Schnittstellen von Drittanbietern verwenden diese Methode und legen entsprechende Antwortspezifikationen fest.

Zusammenfassung

Tatsächlich gibt es kein Problem mit beiden Antwortkörpern. Der Schlüssel liegt darin, die Regeln zwischen Entwicklern festzulegen und nicht beide im Projekt zu verwenden!

Das obige ist der detaillierte Inhalt vonEinführung in die Standardisierung von API-Rückgabewerten (Codebeispiel). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!