针对【API接口通讯参数规范】这篇文章留下的几个问题进行探讨。
问题1
试想一下，如果一个http请求返回一个500给我们，那我们是不是都不用看详情都知道该次请求发生了什么？这正是一个标准的结果码意义所在。在公司所有的系统中，API遵循同一套结果码，那这样同事A在调用同事B的接口时，对于返回的结果码是非常具有可读性的，我们不用面对面交流都知道返回的结果是一个什么样的情况。
XML方案
在此先给出上一篇文章针对Result的另一个方案，是基于XML来定义结果码的，可能有些公司喜欢XML这种配置文件，因为可以不用重新发布应用程序（其实大多数情况下还是需要重新发布的，后面会讲解）。这里面的主要变化是我们不再从枚举ResultCode中获取提示信息，这些提示信息会放在XML上，看看我们的Result中的Message属性的变化
/// <summary>
/// 结果消息
/// </summary>
public string Message
{
get { return _message ?? XmlResultCodeHelper.GetResultMsg((int)Code); }
set { _message = value; }
}
看看我们的这个帮助类
/// <summary>
/// xml结果码帮助类
/// </summary>
public class XmlResultCodeHelper
{
private static List<XmlResultCode> xmlResultCode = new List<XmlResultCode>(); //获取xml里面对应的msg
public static string GetResultMsg(int key)
{
if (xmlResultCode.Count==)
{
dynamic type = (new ErrorCodes()).GetType();
string currentDirectory = Path.GetDirectoryName(type.Assembly.Location);
string path = currentDirectory + "\\XmlResultCodes.xml";
xmlResultCode= path.XmlDeserializeFromFile<List<XmlResultCode>>();
} var code = xmlResultCode.FirstOrDefault(q => q.Code == key);
if(null == code)
throw new InvalidOperationException("没有配置对应的xml节点");
return code.Msg;
} } /// <summary>
/// xml结果码
/// </summary>
public class XmlResultCode
{
public int Code { get; set; } public string Msg { get; set; }
}
这个类主要是帮助我们获取到XmlResultCodes.xml并且返回里面对应的msg，这方法里面的xml反序列方法我就不再贴出来了，大家百度一下即可。
看一下我们的XmlResultCodes.xml，这里看得出是一个键值对
<?xml version="1.0" encoding="utf-8"?>
<ArrayOfErrorCode xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<ErrorCode>
<Code></Code>
<Msg>操作成功</Msg>
</ErrorCode>
<ErrorCode>
<Code></Code>
<Msg>操作失败</Msg>
</ErrorCode>
<ErrorCode>
<Code></Code>
<Msg>登陆失败</Msg>
</ErrorCode>
<ErrorCode>
<Code></Code>
<Msg>参数不正确</Msg>
</ErrorCode>
<ErrorCode>
<Code></Code>
<Msg>用户不存在</Msg>
</ErrorCode>
<ErrorCode>
<Code></Code>
<Msg>没有数据</Msg>
</ErrorCode>
</ArrayOfErrorCode>
再看看我们这个ResultCode枚举，对比上篇文章，已经不需要DisplayAttribute了
public enum ResultCode
{
/// <summary>
/// 操作成功
///</summary>
Ok = , /// <summary>
/// 操作失败
///</summary>
Fail = , /// <summary>
/// 登陆失败
///</summary>
LoginFail = , /// <summary>
/// 参数不正确
///</summary>
InvalidParams = , /// <summary>
/// 用户不存在
///</summary>
NoSuchUser = , /// <summary>
/// 没有该数据
///</summary>
NoRecord = , }
那这种情况ResultCode对我们的意义是什么呢？且看下面例子
//情况1
return Result.FromCode(); //情况2
return Result.FromCode(ResultCode.InvalidParams);
我们虽然英文口语不一定流利：），但是凭借我们的睿智，肯定会让我们选择情况2使程序具有更高的可读性，不然新人接手项目，吐槽是少不了的，难保自己过了段时间再看这样的设计，这返回的13是什么鬼？
OK，XML的方案基本可以了，总结一下步骤：
1. 在ResultCode中定义好自己的英文（使程序具有更高的可读性）和对应枚举的数值
2. 在XmlResultCodes.xml中定义这个数值对应的提示信息
同样我们也会审视这个设计方案的问题所在：为什么会采用XML？就是冲着不用重新发布嘛。是的，改提示信息是可以不用重新发布，但是在xml里面添加了新的节点呢？添加了之后我们得用啊，一样要在业务中调用这个新的节点，还不是一样要重新发布？这样看来我们基于这个XML的设计方案并没有完全达到我们的初衷的。
怎么办？且看下面的问题。
问题2
我们如何做到统一呢？中心式的管理，在管理后台中，把所有的结果码和对应的消息都写入数据库，然后通过Redis加载作为缓存，在获取提示信息的时候访问Redis返回我们需要的信息。
public class ResultCodeHelper
{
public static string GetResultMsg(int key)
{
//从redis数据库根据key获取到value
}
}
这里只是伪代码，大家根据自己的Redis的熟知情况设计方案。
现在这个ResultCode的增删改都只能让管理员在管理后台操作了，开发人员最好是有权限能查看到ResultCode的所有结果码和信息，这样在新增之前才能知道是否存在类似的结果码进而避免重复。修改和删除结果码？最好不要，你有见过Http状态码的更改吗？这种公司级别的通讯规范，作为基础设施架构就最好先设计和定义，后续项目多起来，都可以有据可依。
来看一下我们结果码定义和使用的流程：
1. ResultCode在管理后台的定义和储存
2. 加载到Redis并获取对应值的信息
3. 每个项目都定义好自己的ResultCode对应的枚举和值（使程序具有更高的可读性）
至此我们通过DisplayAttribute和XML获取提示信息这两种方案都已经被分布式缓存Redis方案代替了，我们做了那么多，并且耦合了Redis缓存，这样做究竟有什么好处呢？就像我们的标题阐述的主题一样，规范！规范会让后续的项目管理花费更少的effor。
让我知道如果你有更好的想法！