API接口通讯参数规范
问题引出
通常在很多的公司里面,对于接口的返回值没做太大规范,所以会比较常看到各个项目各自定义随意的返回值,比如以下情况:
1. 直接返回bool值(True或者False)
2. 返回void,只要不是异常信息,默认成功
3. 直接返回异常详情(这个非常不好,通过一些低级的异常,客户可以看到公司的一个技术水平)
4. 返回多个值,还要使用 out 来添加返回参数
5. 。。。
对于项目数量稍微多点的公司来说,接手多个项目的同事估计要吐血,所以项目间的业务通信规范是很有必要的。
解决方案
结合个人项目经验,定义一个专门用来封装返回值信息的通用类,如下:
/// <summary>
/// 返回结果
/// </summary>
public interface IResult
{
/// <summary>
/// 结果状态码
/// </summary>
ResultCode Code { get; set; } /// <summary>
/// 提示信息
/// </summary>
/// <example>操作成功</example>
string Message { get; set; } /// <summary>
/// 是否成功
/// </summary>
bool Success { get; }
} /// <summary>
/// 返回的附带泛型数据
/// </summary>
public interface IResult<TType> : IResult
{
/// <summary>
/// 返回的附带数据
/// </summary>
TType Data { get; set; }
}
这个ResultCode是针对业务操作结果的自定义枚举,用来标志当前返回的一个业务结果
public enum ResultCode
{
/// <summary>
/// 操作成功
///</summary>
[Display(Name = "操作成功")]
Ok = , /// <summary>
/// 操作失败
///</summary>
[Display(Name = "操作失败")]
Fail = , /// <summary>
/// 登陆失败
///</summary>
[Display(Name = "登陆失败")]
LoginFail = , /// <summary>
/// 没有该数据
///</summary>
[Display(Name = "没有数据")]
NoRecord = , /// <summary>
/// 用户不存在
///</summary>
[Display(Name = "用户不存在")]
NoSuchUser = , /// <summary>
/// 未登录
///</summary>
[Display(Name = "未登录")]
Unauthorized = , /// <summary>
/// 未授权
/// </summary>
[Display(Name = "未授权")]
Forbidden = , /// <summary>
/// 无效Token
/// </summary>
[Display(Name = "无效Token")]
InvalidToken = , /// <summary>
/// 参数验证失败
/// </summary>
[Display(Name = "参数验证失败")]
InvalidData = , /// <summary>
/// 无效用户
/// </summary>
[Display(Name = "无效用户")]
InvalidUser =
}
有了以上的接口,我们可以看一下具体实现
public class Result : IResult
{
private string _message; /// <summary>
/// 是否成功
/// </summary>
public bool Success => Code == ResultCode.Ok; /// <summary>
/// 结果码
/// </summary>
public ResultCode Code {get; set;} /// <summary>
/// 提示信息
/// </summary>
public string Message
{
get { return _message ?? Code.DisplayName(); }
set { _message = value; }
} /// <summary>
/// 返回结果,默认成功
/// </summary>
public Result()
{
Code = ResultCode.Ok;
} /// <summary>
/// 返回结果
/// </summary>
/// <param name="code">状态码</param>
/// <param name="message">提示信息</param>
public Result(ResultCode code, string message = null)
{
Code = code;
Message = message;
}
}
这里我们定义了实现类,注意默认的构造函数是返回成功的,这方便我们后面针对业务对这个返回结果再次进行扩展。细心的大家应该注意到了返回的提示信息,我们针对上面的自定义枚举的提示信息会进行显示,后面具体实现再看。先看一下我们的泛型返回结果的实现
/// <summary>
/// 返回结果
/// </summary>
public class Result<TType> : Result, IResult<TType>
{
/// <summary>
/// cotr
/// </summary>
public Result()
{
} /// <summary>
/// 返回结果
/// </summary>
public Result(TType data)
: base(ResultCode.Ok)
{
Data = data;
} /// <summary>
/// 返回结果
/// </summary>
/// <param name="code">状态码</param>
/// <param name="message">提示信息</param>
public Result(ResultCode code, string message = null)
: base(code, message)
{
} /// <summary>
/// 返回结果
/// </summary>
public Result(ResultCode code, string message = null, TType data = default(TType))
: base(code, message)
{
Data = data;
} /// <summary>
/// 返回业务数据
/// </summary>
public TType Data { get; set; }
}
好有了这些,我们在Result类中定义一些静态方法对结果进行封装,这样可以让我们在业务层进行快速的调用
/// <summary>
/// 返回指定 Code
/// </summary>
public static Result FromCode(ResultCode code, string message = null)
{
return new Result(code, message);
} /// <summary>
/// 返回错误信息
/// </summary>
public static Result FromError(string message, ResultCode code = ResultCode.Fail)
{
return new Result(code, message);
} /// <summary>
/// 返回成功
/// </summary>
public static Result Ok(string message = null)
{
return FromCode(ResultCode.Ok, message);
} /// <summary>
/// 返回指定 Code
/// </summary>
public static Result<T> FromCode<T>(ResultCode code, string message = null)
{
return new Result<T>(code, message);
} /// <summary>
/// 返回指定 Code和提示信息
/// </summary>
public static Result<T> FromCode<T>(ResultCode code, T data, string message = null)
{
return new Result<T>(code, message, data);
} /// <summary>
/// 返回错误信息
/// </summary>
public static Result<T> FromError<T>(string message, ResultCode code = ResultCode.Fail)
{
return new Result<T>(code, message);
} /// <summary>
/// 返回数据
/// </summary>
public static Result<T> FromData<T>(T data)
{
return new Result<T>(data);
} /// <summary>
/// 返回数据和提示信息
/// </summary>
public static Result<T> FromData<T>(T data, string message)
{
return new Result<T>(ResultCode.Ok, message, data);
} /// <summary>
/// 返回成功
/// </summary>
public static Result<T> Ok<T>(T data)
{
return FromData(data);
}
好了有了上面这些,我们该如何调用呢?当我们需要直接返回成功时,我们可以这样
return Result.Ok();
前端接收到的结果如下:

当我们需要返回带有数据的结果时,我们可以这样:
var list = new List<string>
{
"lex1",
"lex2"
};
return Result.FromData(list);
前端接收到的结果如下:

当我们需要返回指定Code的时候,如下:
return Result.FromCode(ResultCode.LoginFail);
前端接收到的结果如下:

我们可以看到上面的提示信息是我们在枚举上定义的信息,这是我们在Result类中对Message进行了Code.DisplayName(),思想很简单,就是对枚举进行了扩展,利用DisplayAttribute的公用方法显示信息,那我们怎么知道什么时候调用DisplayAttribute的合适方法呢?
我们先定义一个类DisplayProperty,用来对应DisplayAttribute的各个属性
public enum DisplayProperty
{
/// <summary>
/// 名称
/// </summary>
Name, /// <summary>
/// 短名称
/// </summary>
ShortName, /// <summary>
/// 分组名称
/// </summary>
GroupName, /// <summary>
/// 说明
/// </summary>
Description, /// <summary>
/// 排序
/// </summary>
Order, /// <summary>
/// 水印信息
/// </summary>
Prompt,
}
有了这个之后,我们的枚举扩展方法如下:
/// <summary>
/// 获取枚举说明
/// </summary>
public static string DisplayName(this Enum val)
{
return val.Display(DisplayProperty.Name) as string;
} /// <summary>
/// 获取枚举短名称说明
/// </summary>
public static string DisplayShortName(this Enum val)
{
return val.Display(DisplayProperty.ShortName) as string;
} /// <summary>
/// 获取枚举水印信息
/// </summary>
public static string DisplayPrompt(this Enum val)
{
return val.Display(DisplayProperty.Prompt) as string;
} /// <summary>
/// 获取枚举备注
/// </summary>
public static string DisplayDescription(this Enum val)
{
return val.Display(DisplayProperty.Description) as string;
} /// <summary>
/// 获取枚举指定的显示内容
/// </summary>
public static object Display(this Enum val, DisplayProperty property)
{
var enumType = val.GetType(); var str = val.ToString(); if (enumType.GetAttribute<FlagsAttribute>() != null && str.Contains(","))
{
var array = str.Split(",", StringSplitOptions.RemoveEmptyEntries).Select(o => o.Trim()); var result = array.Aggregate("", (s, s1) =>
{
var f = enumType.GetField(s1); if (f != null)
{
//MethodInfo的扩展,方法在下面
var text = f.Display(property);
return s.IsNullOrEmpty() ? text.ToString() : $"{s},{text}";
} return s;
}); return result.IsNullOrEmpty() ? null : result;
} var field = enumType.GetField(str);
if (field != null)
{
return field.Display(property);
} return null;
}
再看针对MemberInfo的一个扩展,这里面就根据我们传入的DisplayProperty属性值调用了DisplayAttribute的对应方法
/// <summary>
/// 获取枚举指定的显示内容
/// </summary>
public static object Display(this MemberInfo memberInfo, DisplayProperty property)
{
if (memberInfo == null) return null; var display = memberInfo.GetAttribute<DisplayAttribute>(); if (display != null)
{
switch (property)
{
case DisplayProperty.Name:
return display.GetName();
case DisplayProperty.ShortName:
return display.GetShortName();
case DisplayProperty.GroupName:
return display.GetGroupName();
case DisplayProperty.Description:
return display.GetDescription();
case DisplayProperty.Order:
return display.GetOrder();
case DisplayProperty.Prompt:
return display.GetPrompt();
}
} return null;
}
到此我们的这个业务通讯结果已经可以了,再细想,有几个问题需要我们解决的:
1. ResultCode的意义?
2. 公司这么多项目都这样的话,如果某个系统需要新增一个提示或者英文不规范修改了,那会不会造成不一致呢?
后续文章会针对这些问题和可能存在的问题进行探讨!
API接口通讯参数规范的更多相关文章
- API接口通讯参数规范(2)
针对[API接口通讯参数规范]这篇文章留下的几个问题进行探讨. 问题1 试想一下,如果一个http请求返回一个500给我们,那我们是不是都不用看详情都知道该次请求发生了什么?这正是一个标准的结果码意义 ...
- Restful API 接口设计标准及规范
Restful API 接口设计标准以及规范 RESTful概念 理解和评估以网络为基础的应用软件的架构设计,得到一个功能强.性能好.适宜通信的架构.REST指的是一组架构约束条件和原则." ...
- API接口防止参数篡改和重放攻击
{近期领导要求我对公司业务的支付类的ocr接口做研究,是否存在支付接口重放攻击,so.....} API重放攻击(Replay Attacks)又称重播攻击.回放攻击.他的原理就是把之前窃听到的数据原 ...
- RESTful API接口文档规范小坑
希望给你3-5分钟的碎片化学习,可能是坐地铁.等公交,积少成多,水滴石穿,谢谢关注. 前后端分离的开发模式,假如使用的是基于RESTful API的七层通讯协议,在联调的时候,如何避免配合过程中出现问 ...
- 如何写出安全的API接口(参数加密+超时处理+私钥验证+Https)- 续(附demo)
上篇文章说到接口安全的设计思路,如果没有看到上篇博客,建议看完再来看这个. 通过园友们的讨论,以及我自己查了些资料,然后对接口安全做一个相对完善的总结,承诺给大家写个demo,今天一并放出. 对于安全 ...
- Spring框架学习笔记(9)——API接口设计相关知识及具体编码实现
最近需要设计一个API服务器,想要把API接口搞得规范一下,就通过网上搜集到了一些资料,以下便是自己的一些理解以及相关的具体实现 本文采用的是spring boot+maven的方案 restful规 ...
- API 接口开发规范
整体规范建议采用RESTful 方式来实施. 协议 API与用户的通信协议,总是使用HTTPs协议,确保交互数据的传输安全. 域名 应该尽量将API部署在专用域名之下.https://api.exam ...
- day71:drf:API接口&Restful API规范&Django Rest Framework&drf中的序列化和反序列化功能
目录 1.web应用模式 2.API接口 3.Restful API规范 4.序列化 5.Django Rest Framework 1.drf的简单介绍 2.drf的特点 3.如何安装drf 4.d ...
- 后端API接口的错误信息返回规范
前言 最近我司要制定开发规范.在讨论接口返回的时候,后端的同事询问我们前端,错误信息的返回,前端有什么意见? 所以做了一些调研给到后端的同事做参考. 错误信息返回 在使用API时无可避免地会因为各种情 ...
随机推荐
- Java中的基本类型和引用类型变量的区别
Java中的基本类型和引用类型变量的区别 学了一年多,说实话你要我说这些东西我是真说不出来是啥意思 基本类型: 基本类型自然不用说了,它的值就是一个数字,一个字符或一个布尔值. 引用类型: ...
- file.go
// return int64(f.offset), errors.New("offset > file.size") //}else { // ...
- iOS指纹识别Touch ID的安全性探讨
苹果公司在 iPhone 5s 的发布会上公布了全新的指纹识别安全技术,也就是 Touch ID,开创了生物安全识别技术在便携设备上使用的新篇章.此后,苹果还将此技术带到了 iPad 上.此前没有任何 ...
- laravel5.5解决小程序登陆态的问题
修改一个文件 : vendor\laravel\framework\src\Illuminate\Session\Middleware\StartSession.php 找到getSession()方 ...
- python常见的报错提示
在运行或编写一个程序时常会遇到错误异常,这时python会给你一个错误提示类名,告诉出现了什么样的问题(Python是面向对象语言,所以程序抛出的异常也是类).能很好的理解这些错误提示类名所代表的意思 ...
- 一份完整的阿里云 Redis 开发规范,值得收藏!
来源:yq.aliyun.com/articles/531067 作者:付磊-起扬 本文主要介绍在使用阿里云Redis的开发规范,从下面几个方面进行说明. 键值设计 命令使用 客户端使用 相关工具 通 ...
- 企业私有源代码上传github致入侵之大疆案判决了
事件简单回顾: 1.2017年8月28日,大疆宣布“大疆威胁识别奖励计划”,最高3万美元: 2.然而在此之前,大疆农业事业部某员工将企业私有源代码上传到了github: 3.就职于大疆竞对公司Depa ...
- Python的re模块
什么是re模块,re模块有什么作用? re模块是Python提供的一个正则表达式相关的模块,主要是针对字符串进行模糊匹配,所以在字符串匹配这一功能上,re相当专业. 什么是模糊匹配? 之前的学习字符串 ...
- 【反编译系列】一、反编译代码(dex2jar + jd-gui)和反编译资源(apktool)
版权声明:本文为HaiyuKing原创文章,转载请注明出处! [反编译系列]二.反编译代码(jeb) [反编译系列]三.反编译神器(jadx) [反编译系列]四.反编译so文件(IDA_Pro) 概述 ...
- kube-proxy的功能
Kube-proxy的功能 我们知道POD的IP是动态分配的而且经常会变,所以为了可以通过一个不太容易变化的IP访问POD就会使用一个叫做service的东西,通过标签选择器和POD进行关联. Ser ...