如何设计 API 接口,实现统一格式返回?

在移动互联网,分布式,微服务盛行的今天,现在项目绝大部分都采用的微服务框架,前分离分离方式,(题外话:前重新的工作分配越来越明确,现在的前端都称为大前端,技术栈以及生态圈都已经非常成熟;以前官员人员瞧不起前端人员,那现在高层人员要重新认识一下前端,前端已经很成体系了)。

一般系统的大致整体架构图如下:

需要说明的是,有些小伙伴会回复说,这个架构太简单了吧,太low了,什么网关啊,缓存啊,消息中间件啊,都没有。因为老顾介绍主要介绍的是API接口,所以我们聚焦点,其他的模块小伙伴们自行去补充。

前端和前端进行交互,前端按约定的请求URL路径,并合并相关参数,进入服务器接收请求,进行业务处理,返回数据给前端。

接口相互作用

前端和前端进行交互,前端按约定的请求URL路径,并合并相关参数,进入服务器接收请求,进行业务处理,返回数据给前端。

针对URL路径的restful风格,以及引用参数的公共请求头的要求(如:app_version,api_version,device等),老顾这里就不介绍了,小伙伴们可以自行去了解,也比较简单。

前端服务器如何实现把数据返回给前端?

返回格式

最初返回给前端我们一般用JSON体方式,定义如下:

{
  #返回状态码
  code:integer,
  #返回信息描述
  message:string,
  #返回值
  data:object
}

CODE状态码

code返回状态码,一般小伙伴们是在开发的时候需要什么,就添加什么。

如接口要返回用户权限异常,我们加一个状态码为101吧,下一次又要加一个数据参数异常,就加一个102的状态码。这样虽然能够照常满足业务,但状态码太凌乱了

我们应该可以参考HTTP请求返回的状态码

:下面是常见的HTTP状态码:
200 - 请求成功
301 - 资源(网页等)被永久转移到其它URL
404 - 请求的资源(网页等)不存在
500 - 内部服务器错误

我们可以参考这样的设计,这样的好处就把错误类型归类到某个区间内,如果区间不够,可以设计成4个数字。

#1000~1999 区间表示参数错误
#2000~2999 区间表示用户错误
#3000~3999 区间表示接口异常

这样前端开发人员在得到返回值后,根据状态码就可以知道,大概什么错误,再根据消息相关的信息描述,可以快速定位。

阅读剩余
THE END