支付中心接口设计之参数命名
2017-06-10 21:07
288 查看
目前,java版支付中心处在研发阶段。下午,特有钻研精神的云龙同学饶有兴趣的问我“战哥,你觉得表字段用哪种命名方式比较好呢?”
所用的db是mysql,他是想征求一下我的看法,是用驼峰式命名还是小写加下划线方式。
我直截了当地说用驼峰式。为什么? 我认为,像java语言或.net语言,实体类的属性一般是遵从驼峰式命名的(稍有不同的是java一般首字母小写,而.net是首字母大写)。我们的程序里的数据访问层一般均采用ORM框架。如果表字段是小写字母+下划线,那么,相应的POJO/POCO实体类的属性也会是小写字母+下划线,这样,违背了常规的驼峰式命名,在代码的整洁方面不太好。
接着,如我所期,云龙问“那你支付中心对外的接口参数为什么用小写+下划线的方式呢?”
我答道,对外提供的接口,考虑到不同语言如php\java\.net的对接,
如果用驼峰式。 首先,我们用word编写接口文档时,在参数表格里输入参数名后,如果按tab键,则word默认首字母是大写的。而如果恰好我们的首字母是小写时,如果我们在编写时忽略了这个细节,这就会给对接者带来疑惑(产品设计上有一条重要的原则:Don't Make Me Think,同样适用于软件设计); 更甚之,如果签名规则要求的签名原串包括参数名时,那么,在接口对接联调时,我们很可能会因此而造成双方的“不必要”沟通。
如果用小写+下划线。 首先,这种方式规避了上面驼峰式命名的不足。 其次,跨语言程序员之间都会认可。
云龙和伟业听后表示赞同。
我解释,我们开发接口踩过的坑太多了,逐渐的就要考虑这些细节。
![](https://images2015.cnblogs.com/blog/202192/201706/202192-20170610204643715-1421417580.png)
![](https://images2015.cnblogs.com/blog/202192/201706/202192-20170618112942196-770106194.png)
【另面观】
其实,也许是从事IT项目管理的职业病,我喜欢考虑项目成本,系统设计方面,始终坚持通过合理设计规避不必要的沟通甚至互撕。
像上面支付接口的参数,如果不考虑命名形式,用驼峰式,势必会带来后续甲乙双方联调过程中的沟通成本。那么,倘若我们改为小写加下划线的形式,就会规避这些真的是不必要的沟通。 ——这就是软件意识。
有些程序员一天的工作就是商户接口对接联调支持。有些领导看到下属员工一天忙碌的对接,认为其工作很饱满。
【延伸】
我也饶有兴趣,忽然在想,我们支付中心对外提供的这种接口在技术层面叫作什么呢? api是应用程序接口,即程序包里的公开的方法及对这些方法的说明。而这种通过http发布的接口,是什么呢? rpc接口?rmi接口?webapi? 我也去找云龙和伟业探讨,他们说就是接口嘛,笑我太爱琢磨了。
我常常就这样较真儿,当然,我也不认为这种较真儿是什么缺点。于是,为了一个细节,我会去查看好些技术帖子和blog。于是,我也再了解了一下rpc、web Service、web api。
今天周六,加班的同事早已回家。我从洗手间回到工位,办公区周围的昏黑,窗外三环上疾驰的车辆,CBD夜景灯火阑珊,不觉中渲染出我的孤寂。大周末的,是时候回家陪陪孩子做点家务了。
所用的db是mysql,他是想征求一下我的看法,是用驼峰式命名还是小写加下划线方式。
我直截了当地说用驼峰式。为什么? 我认为,像java语言或.net语言,实体类的属性一般是遵从驼峰式命名的(稍有不同的是java一般首字母小写,而.net是首字母大写)。我们的程序里的数据访问层一般均采用ORM框架。如果表字段是小写字母+下划线,那么,相应的POJO/POCO实体类的属性也会是小写字母+下划线,这样,违背了常规的驼峰式命名,在代码的整洁方面不太好。
接着,如我所期,云龙问“那你支付中心对外的接口参数为什么用小写+下划线的方式呢?”
我答道,对外提供的接口,考虑到不同语言如php\java\.net的对接,
如果用驼峰式。 首先,我们用word编写接口文档时,在参数表格里输入参数名后,如果按tab键,则word默认首字母是大写的。而如果恰好我们的首字母是小写时,如果我们在编写时忽略了这个细节,这就会给对接者带来疑惑(产品设计上有一条重要的原则:Don't Make Me Think,同样适用于软件设计); 更甚之,如果签名规则要求的签名原串包括参数名时,那么,在接口对接联调时,我们很可能会因此而造成双方的“不必要”沟通。
如果用小写+下划线。 首先,这种方式规避了上面驼峰式命名的不足。 其次,跨语言程序员之间都会认可。
云龙和伟业听后表示赞同。
我解释,我们开发接口踩过的坑太多了,逐渐的就要考虑这些细节。
![](https://images2015.cnblogs.com/blog/202192/201706/202192-20170610204643715-1421417580.png)
![](https://images2015.cnblogs.com/blog/202192/201706/202192-20170618112942196-770106194.png)
【另面观】
其实,也许是从事IT项目管理的职业病,我喜欢考虑项目成本,系统设计方面,始终坚持通过合理设计规避不必要的沟通甚至互撕。
像上面支付接口的参数,如果不考虑命名形式,用驼峰式,势必会带来后续甲乙双方联调过程中的沟通成本。那么,倘若我们改为小写加下划线的形式,就会规避这些真的是不必要的沟通。 ——这就是软件意识。
有些程序员一天的工作就是商户接口对接联调支持。有些领导看到下属员工一天忙碌的对接,认为其工作很饱满。
【延伸】
我也饶有兴趣,忽然在想,我们支付中心对外提供的这种接口在技术层面叫作什么呢? api是应用程序接口,即程序包里的公开的方法及对这些方法的说明。而这种通过http发布的接口,是什么呢? rpc接口?rmi接口?webapi? 我也去找云龙和伟业探讨,他们说就是接口嘛,笑我太爱琢磨了。
我常常就这样较真儿,当然,我也不认为这种较真儿是什么缺点。于是,为了一个细节,我会去查看好些技术帖子和blog。于是,我也再了解了一下rpc、web Service、web api。
今天周六,加班的同事早已回家。我从洗手间回到工位,办公区周围的昏黑,窗外三环上疾驰的车辆,CBD夜景灯火阑珊,不觉中渲染出我的孤寂。大周末的,是时候回家陪陪孩子做点家务了。
![](https://images2015.cnblogs.com/blog/202192/201706/202192-20170610212116747-399638498.jpg)
相关文章推荐
- 接口设计:以数据为中心,从需求和变化的角度考虑
- 08_传智播客hibernate教程_hql的命名参数与Query接口的分页查询
- 微信支付接口,提示:调用支付jsapi缺少参数: $key0$
- 如何写出安全的API接口?接口参数加密签名设计思路
- 基于python的接口测试框架设计(二)配置一些参数及文件
- 指针 引用和auto_ptr,论接口参数设计的原则
- 微信h5支付接口开发,出现错误‘商家参数格式有误,请联系商家解决’,访问无法mweb_url
- 统一参数配置中心设计
- (第3章:接口与API设计)第15条:用前缀避免命名空间冲突
- 如何写出安全的API接口?接口参数加密签名设计思路
- C#学习笔记(五)中级 方法的重载,参数,继承和多态,异常处理,命名空间,接口,泛型
- 探讨在线支付平台支付接口的设计
- 探讨在线支付平台支付接口的设计
- C++ 11可变参数接口设计在模板编程中应用的一点点总结
- 微信接口出现“调用支付jsapi缺少参数appid”
- 浅谈log4cpp接口字符串参数类型的设计
- 如何设计接口的参数以减少对接口的修改
- 架构设计--用户端全http参数接口详细说明v1
- 如何写出安全的API接口?接口参数加密签名设计思路
- 设置公众号支付参数,检测微信支付提交参数是否合法,公众号支付接口开发5