前后端分离之——接口数据返回---标准格式

开发中,如果前端和后端,在没有统一返回数据格式,我们来看一下会发生什么:

后台开发人员A,在接口返回时,习惯返回一个返回码code=0000,然后返回数据;

后台开发人员B,在接口返回时,习惯直接返回一个boolean类型的success=true,然后返回数据;

后台开发人员C,在接口返回时,习惯在接口失败时返回码为code=0000。

可以看到,上面的三个开发人员,都没有大问题,没有谁对谁错,只要给前端接口文档,前端都是可以接上接口的。但是,在项目功能越来越多,接口数量持续增长时,对开发人员而言,就是一种灾难,同一个前端,如果对接A和C,那她接接口时会很崩溃。因为返回的code,同样是0000,但是一个代表成功,一个代表失败,这时前端就会去找两个人沟通,看可不可以统一一下,但是两个人一看,最近写了几十个接口了,还和别人对接过,牵一发动全身,没法做改动了。看,这就是灾难。

所以,在项目开发中,初期搭建框架时,定好通用的接口数据返回格式,定义好全局的状态码,是非常有必要的。一个项目,甚至整个公司,遵循同一套接口返回格式规范,这样可以极大的提高进度,降低沟通成本。

下面的两个类,一个是数据返回格式,是自定义的,很简单,但是可通用,这里分享一下,返回给前端时,根据情况,直接调用此类中的方法做返回值;另一个是状态码,这个可以根据项目实际情况,自己做修改。

接口数据返回格式:

package response;

import domain.ReturnCode;

/**
 * Created by lightClouds917
 * Date 2017/11/10
 * Description:接口统一返回格式
 */
public class ResponseWrapper {
    private Integer code;//状态码
    private Boolean isSuccess;//状态
    private String massege;//消息
    private Object result;//数据对象

    /**
    * 无参构造器
    */
    public Result(){
    super();
    }

    /**
    * 只返回状态,状态码,消息
    * @param statu
    * @param code
    * @param massege
    */
    public Result(Boolean success, Integer code, String massege){
    super();
    this.isSuccess=success;
    this.code=code;
    this.massege=massege;
    }

    /**
    * 只返回状态,状态码,数据对象
    * @param statu
    * @param code
    * @param object
    */
    public Result(Boolean success, Integer code, Object result){
    super();
    this.isSuccess=success;
    this.code=code;
    this.result=result;
    }

    /**
    * 返回全部信息即状态,状态码,消息,数据对象
    * @param statu
    * @param code
    * @param massege
    * @param result
    */
    public Result(Boolean success, Integer code, String massege, Object result){
    super();
    this.isSuccess=success;
    this.code=code;
    this.massege=massege;
    this.result=result;
    }

    public Integer getCode() {
    return code;
    }

    public void setCode(Integer code) {
    this.code = code;
    }

    public Boolean getIsSuccess() {
    return isSuccess;
    }

    public void setIsSuccess(Boolean isSuccess) {
    this.isSuccess = isSuccess;
    }

    public String getMassege() {
    return massege;
    }

    public void setMassege(String massege) {
    this.massege = massege;
    }

    public Object getResult() {
    return result;
    }

    public void setResult(Object result) {
    this.result = result;
    }

}
 

状态码

public enum ReturnCode {

    SUCCESS(0000,"查询成功"),
    NODATA(0001,"查询成功无记录"),
    FEAILED(0002,"查询失败"),
    ACCOUNT_ERROR(1000, "账户不存在或被禁用"),
    API_NOT_EXISTS(1001, "请求的接口不存在"),
    API_NOT_PER(1002, "没有该接口的访问权限"),
    PARAMS_ERROR(1004, "参数为空或格式错误"),
    SIGN_ERROR(1005, "数据签名错误"),
    AMOUNT_NOT_QUERY(1010, "余额不够,无法进行查询"),
    API_DISABLE(1011, "查询权限已被限制"),
    UNKNOWN_IP(1099, "非法IP请求"),
    SYSTEM_ERROR(9999, "系统异常");

    private int code;
    private String msg;

    public int getCode() {
        return code;
    }

    public String getMsg() {
        return msg;
    }

    private ReturnCode(int code, String msg) {
        this.code = code;
        this.msg = msg;
    }
}

原文地址:https://www.cnblogs.com/tanzq/p/9754510.html

时间: 2024-08-28 01:01:34

前后端分离之——接口数据返回---标准格式的相关文章

接口数据返回---标准格式

开发中,如果前端和后端,在没有统一返回数据格式,我们来看一下会发生什么: 后台开发人员A,在接口返回时,习惯返回一个返回码code=0000,然后返回数据: 后台开发人员B,在接口返回时,习惯直接返回一个boolean类型的success=true,然后返回数据: 后台开发人员C,在接口返回时,习惯在接口失败时返回码为code=0000. 可以看到,上面的三个开发人员,都没有大问题,没有谁对谁错,只要给前端接口文档,前端都是可以接上接口的.但是,在项目功能越来越多,接口数量持续增长时,对开发人员

django的crsf机制防御详解及在前后端分离中post数据到django-vue

django的crsf机制防御详解及在前后端分离中post数据到django 更新于: 2018-07-28 |  分类于 django CSRF(Cross Site Request Forgery) 跨站点伪造请求 某个用户已经登陆了你的网站,另外有一个恶意的网站有一个指向你网站的链接,那么当用户点击这个链接时,就会请求你的网站,但是你的网站以为是用户发来的请求,这时恶意网站就得逞了. django的应对措施 用户在post请求时,发送给用户一个token,然后在django内部实现了一个校

webpack 前后端分离开发接口调试解决方案,proxyTable解决方案

如果你有单独的后端开发服务器 API,并且希望在同域名下发送 API 请求 ,那么代理某些 URL 会很有用. dev-server 使用了非常强大的 http-proxy-middleware 包.更多高级用法,请查阅其文档. 在 localhost:3000 上有后端服务的话,你可以这样启用代理: proxy: { "/api": "http://localhost:3000" } 请求到 /api/users 现在会被代理到请求 http://localhos

vue的初识与简单使用---前后端分离通过接口调取数据

vue的安装 #### 1.环境搭建 ''' - 安装node ``` 官网下载安装包,傻瓜式安装:https://nodejs.org/zh-cn/ ``` - 安装cnpm ``` npm install -g cnpm --registry=https://registry.npm.taobao.org ``` - 安装脚手架 ``` cnpm install -g @vue/cli ``` - 清空缓存处理 ``` npm cache clean --force ``` #### 2.项

【怪咖】------前后端分离与不分离的区别------

前后端分离,首先所有的程序以数据为基础的,没有数据的程序没有实际意义,程序的本质就是对程序的增删改查,其实前后端分离就是把数据操作和显示分离出来.前端专注做数据显示,通过文字,图片或者图标等方式让数据形象直观的显示出来,后端专注做数据的操作,前端通过后端提供的接口把数据发给后端,有后端对数据进行修改操作. 所以在前后端分离的应用模式中,后端仅返回前端所需的数据,不再渲染html页面,不再控制前端的效果.至于前端用户看到什么效果,从后端强求的数据如何加载到前端中,都由前端自己决定,网页有网页的处理

前后端分离与不分离,一点点理解

1>为什么要前后端分离? 现有开发模式的使用场景 前后端职责不清 开发效率的问题 对前端发挥的局限 2>前后端分离会带来什么变化? 1.彻底解放前端 制作页面的时候,不需要后台配置服务器环境,可以自己配置路由,前端代码里面不会掺杂后端的代码以及逻辑 2.提高工作的效率 3.局部性能提升 4.降低了维护成本 3>前后端分离的核心:前端负责调用ajax实现数据显示(view层和controller层),后台提供数据(API)接口(model层). 在前后端没有分离前,后端需要渲染页面或者重定

SpringBootSecurity学习(13)前后端分离版之JWT

JWT 使用 前面简单介绍了把默认的页面登录改为前后端分离的接口异步登录的方法,可以帮我们实现基本的前后端分离登录功能.但是这种基本的登录和前面的页面登录还有一个一样的地方,就是使用session和cookie来维护登录状态,这种方法的问题在于,扩展性不好.单机当然没有问题,如果是服务器集群,或者是跨域的服务导向架构,就要求 session 数据共享,每台服务器都能够读取 session. 一种解决方案是 session 数据持久化,写入redis或别的持久层.各种服务收到请求后,都向持久层请求

前后端分离与前后端不分离的区别

前后端不分离 在前后端不分离的应用模式中,前端页面看到的效果都是由后端控制,由后端渲染页面或重定向,也就是后端需要控制前端的展示,前端与后端的耦合度很高. 这种应用模式比较适合纯网页应用,但是当后端对接App时,App可能并不需要后端返回一个HTML网页,而仅仅是数据本身,所以后端原本返回网页的接口不再适用于前端App应用,为了对接App后端还需再开发一套接口. 请求的数据交互如下图: 前后端分离 在前后端分离的应用模式中,后端仅返回前端所需的数据,不再渲染HTML页面,不再控制前端的效果.至于

开源项目练习EF+jQueryUI前后端分离设计

最近大家流行把项目开源,我也来玩玩.只是开源公司项目不好,小弟只好从公司项目经验上另外弄出一套练习开源给大家. 这个项目可以做简单的团队任务系统(做一些简单的任务分配,没经过严格测试.功能单一别喷啊,有想用的可以自己往里面加-估计想用的话还得做任务进度统计,生成点图表什么的). 这个项目用到了EF.WebService.html.jQuery.jQuery UI.jqGrid.前后端分离通过json数据交互,纯Ajax项目(除上传功能) jQueryUI有几个点优化,如dialog close时