牛皮的程序猿后端返回值怎么定义

简介: 在后端接口封装中,通常会统一返回数据格式,确保稳定性和可预测性。常见的模式包括状态码(如`code`或`ret`)、状态信息(`message`或`msg`)、核心数据(`data`)。`success`字段提供了一种直观判断接口是否成功的标志。例如:

在后端接口封装中,我们一般都会对返回的数据做一个封装,以防止系统出现不可预期的数据结构和类型。比如这样:

结构体 1

{
   
  "success": true,
  "code": 200,
  "message": "成功",
  "data": {
   
    "items": [
      {
   
        "id": "1",
        "name": "小王",
        "identified": "JavaPub博主"
      }
    ]
  }
}

结构体 2

{
   
    "ret": 200,
    "data": {
   
        "title": "Default Api",
        "content": "王哥 您好,欢迎使用 apifather!",
        "version": "1.1.0",
        "time": 14231428021
    },
    "msg": ""
}

不论如何定义,多一个或少一个字段,我们都需要统一规范。接下来我们拆解一下,

首先,通过观察,一定要有状态码,也就是案例中的 coderet ,通过状态码可以知道当前程序哪里出了问题,比如 200 就是成功。有同学会问,为何不用 data 来判断,为空或者为 0 就是错误,当然不行。

比如:下面这个结构,data 长度虽然等于 0,但是这属于确实没查到数据,而不是程序出错。

{
   
    "ret": 200,
    "data": [],
    "msg": ""
}

再看 data,这个毋庸置疑,它是接口的核心数据,也是接口对外提供的业务数据。

再看 message 或者称为 msg,它是给状态做一个文字说明。比如,有个老六在定义了一个状态码(666),第一次调用这个接口的同学可能并不知道返回的状态码含义、也不想去查接口文档,我加个描述:(老六的接口不通啦),调用者就一目了然了。

最后看 success 字段,这个字段是为了更规范而加的,方便前端直接将接口响应状态展示。比如:用户登录成功,可以展示一个 true,或者前端在判断时也可以写更简洁的代码 if result.success:。毕竟将(老六的接口不通啦)描述直接展示出来显得不太正式。

基于以上几点,我们的返回结构这样定义:

ApiResponse.class

// 定义API响应结构体
public class ApiResponse<T> {
   
    private int status; // HTTP状态码
    private String message; // 状态信息
    private T data; // 返回的数据,泛型支持返回不同类型的数据

    // 构造函数
    public ApiResponse(ResponseStatus status) {
   
        this.status = status.getCode();
        this.message = status.getMessage();
    }

    // 带数据的构造函数
    public ApiResponse(ResponseStatus status, T data) {
   
        this(status);
        this.data = data;
    }

    // Getter和Setter方法
    // ...
}

定义完返回结构后,我们需要定义状态的枚举值。这是为了定一个统一的规范,方便开发时状态码搞混。

// 定义状态码枚举
public enum ResponseStatus {
   
    SUCCESS(200, "操作成功"),
    ERROR(500, "服务器内部错误"),
    BAD_REQUEST(400, "请求参数错误"),
    NOT_FOUND(404, "资源未找到"),
    UNAUTHORIZED(401, "未授权"),
    FORBIDDEN(403, "禁止访问");

    private final int code;
    private final String message;

    ResponseStatus(int code, String message) {
   
        this.code = code;
        this.message = message;
    }

    public int getCode() {
   
        return code;
    }

    public String getMessage() {
   
        return message;
    }
}

如何使用呢

@GetMapping("/users/{id}")
public ResponseEntity<ApiResponse<User>> getUser(@PathVariable Long id) {
   
    try {
   
        User user = userService.getUserById(id);
        if (user != null) {
   
            return ResponseEntity.ok(new ApiResponse<>(ResponseStatus.SUCCESS, user));
        } else {
   
            return ResponseEntity.status(HttpStatus.NOT_FOUND)
                                 .body(new ApiResponse<>(ResponseStatus.NOT_FOUND));
        }
    } catch (Exception e) {
   
        // 这里可以根据异常类型返回不同的错误状态码和消息
        return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR)
                             .body(new ApiResponse<>(ResponseStatus.ERROR));
    }
}

这里使用了 Spring 自带的返回结构体 ResponseEntity 进行封装。

获取到的结果是这样的:

{
   
  "code": 200,
  "message": "操作成功",
  "data": {
   
    "id": "1",
    "name": "javapub",
    "age": 18
  }
}

原文地址: https://javapub.net.cn/star/project/user-center/

目录
相关文章
|
2月前
|
监控 NoSQL Java
后端接口性能优化分析-问题发现&问题定义(下)
后端接口性能优化分析-问题发现&问题定义
92 0
|
2月前
|
SQL 缓存 监控
后端接口性能优化分析-问题发现&问题定义(上)
后端接口性能优化分析-问题发现&问题定义
480 0
|
JSON 前端开发 API
后端API接口标准定义
后端API接口标准定义
187 0
|
存储 弹性计算 运维
我的 Serverless 实战 — Serverless 架构理念 ( 后端服务器发展 | Serverless 与 ServerFul | Serverless 定义 | 架构优缺点 )
我的 Serverless 实战 — Serverless 架构理念 ( 后端服务器发展 | Serverless 与 ServerFul | Serverless 定义 | 架构优缺点 )
433 0
|
前端开发 JavaScript .NET
【nodejs】让nodejs像后端mvc框架(asp.net mvc )一样处理请求--控制器的声明定义和发现篇(3/8)
文章目录 前情概要 前面文章把路由已经介绍的差不多了,包括url映射,路由选择等。接下来讲一讲controller的一些基本规则 BaseController的所有代码都在这里拉。相当简单。 主要逻辑:我们的组件接到请求后,根据url规则找到对应的controller和要处理的请求的action后,直接new一个controller出来,把req,res等对象传递给controller对象。
1010 0
|
3天前
|
数据管理 物联网 开发者
现代化后端开发中的微服务架构设计与实现
在当今快速发展的软件开发领域,微服务架构已成为构建高效、可扩展和灵活的后端系统的重要方式。本文将探讨微服务架构的设计原则、实现方法以及应用场景,帮助开发者理解如何在项目中成功应用微服务。【7月更文挑战第4天】
16 2
|
10天前
|
IDE Java 开发工具
Spring Boot:加速Java后端开发的现代化利器
在当今快速迭代的软件开发环境中,Spring Boot 已成为Java后端开发领域的首选框架。作为Spring家族的一员,它以“约定优于配置”的设计理念,极大地简化了传统Spring应用的配置和部署过程,让开发者能够更加专注于业务逻辑的实现。本文将探讨Spring Boot的核心优势,并通过一个简单的示例展示如何快速启动一个基于Spring Boot的Java Web应用。
27 1
|
5天前
|
弹性计算 运维 Kubernetes
探索后端开发的未来:微服务架构与容器化技术
在数字化时代的浪潮中,后端开发正经历着前所未有的变革。微服务架构的兴起和容器化技术的普及,不仅重新定义了软件的开发、部署和管理方式,还为后端开发带来了新的挑战和机遇。本文将深入探讨微服务架构和容器化技术如何影响后端开发的未来,通过数据支撑和逻辑推理,揭示这些技术趋势背后的科学原理和实际应用价值。
|
4天前
|
设计模式 弹性计算 监控
后端开发中的微服务架构:优势、挑战与实施策略
在现代软件开发中,微服务架构已成为一种流行的设计模式,特别是在后端开发领域。该架构风格通过将应用程序分解为一组小型、松耦合的服务,旨在提升可维护性、可扩展性和敏捷性。本文深入探讨了微服务架构的关键优势,面临的主要挑战,以及成功实施微服务的策略。通过引用业界案例和最新研究,文章提供了对微服务架构综合理解的视角,并讨论了如何在不断变化的技术环境中保持其有效性。

热门文章

最新文章