支付中心接口设计之参数命名

目前，java版支付中心处在研发阶段。下午，特有钻研精神的云龙同学饶有兴趣的问我“战哥，你觉得表字段用哪种命名方式比较好呢？”

所用的db是mysql，他是想征求一下我的看法，是用驼峰式命名还是小写加下划线方式。

我直截了当地说用驼峰式。为什么？ 我认为，像java语言或.net语言，实体类的属性一般是遵从驼峰式命名的（稍有不同的是java一般首字母小写，而.net是首字母大写）。我们的程序里的数据访问层一般均采用ORM框架。如果表字段是小写字母+下划线，那么，相应的POJO/POCO实体类的属性也会是小写字母+下划线，这样，违背了常规的驼峰式命名，在代码的整洁方面不太好。

接着，如我所期，云龙问“那你支付中心对外的接口参数为什么用小写+下划线的方式呢？”

我答道，对外提供的接口，考虑到不同语言如php\java.net的对接，

• 如果用驼峰式。 首先，我们用word编写接口文档时，在参数表格里输入参数名后，如果按tab键，则word默认首字母是大写的。而如果恰好我们的首字母是小写时，如果我们在编写时忽略了这个细节，这就会给对接者带来疑惑（产品设计上有一条重要的原则：Don't Make Me Think，同样适用于软件设计）； 更甚之，如果签名规则要求的签名原串包括参数名时，那么，在接口对接联调时，我们很可能会因此而造成双方的“不必要”沟通。
• 如果用小写+下划线。 首先，这种方式规避了上面驼峰式命名的不足。 其次，跨语言程序员之间都会认可。

云龙和伟业听后表示赞同。
我解释，我们开发接口踩过的坑太多了，逐渐的就要考虑这些细节。

wepapi接口设计细节 letter-case

【另面观】
其实，也许是从事IT项目管理的职业病，我喜欢考虑项目成本，系统设计方面，始终坚持通过合理设计规避不必要的沟通甚至互撕。

像上面支付接口的参数，如果不考虑命名形式，用驼峰式，势必会带来后续甲乙双方联调过程中的沟通成本。那么，倘若我们改为小写加下划线的形式，就会规避这些真的是不必要的沟通。 ——这就是软件意识。
有些程序员一天的工作就是商户接口对接联调支持。有些领导看到下属员工一天忙碌的对接，认为其工作很饱满。

【延伸】
我也饶有兴趣，忽然在想，我们支付中心对外提供的这种接口在技术层面叫作什么呢？ api是应用程序接口，即程序包里的公开的方法及对这些方法的说明。而这种通过http发布的接口，是什么呢？ rpc接口？rmi接口？webapi？ 我也去找云龙和伟业探讨，他们说就是接口嘛，笑我太爱琢磨了。
我常常就这样较真儿，当然，我也不认为这种较真儿是什么缺点。于是，为了一个细节，我会去查看好些技术帖子和blog。于是，我也再了解了一下rpc、web Service、web api。

今天周六，加班的同事早已回家。我从洗手间回到工位，办公区周围的昏黑，窗外三环上疾驰的车辆，CBD夜景灯火阑珊，不觉中渲染出我的孤寂。大周末的，是时候回家陪陪孩子做点家务了。