系统交互之接口开发经验谈

这里所谓的接口，是系统与系统之间的信息交互通道。

　　对于一个企业，一般来说肯定不会只有一个数据平台，也就是说不止一个系统。然而，在实际的生产上，由于业务需要，各个平台的数据要在一定程度上做到共享。这就要使用到接口。

　　最近一直在开发，测试某银行信贷系统与票据系统的接口，从这其中，结合项目实际，分享一些关于接口的开发经验。

　　首先：描述下接口的工作原理。跟所有的ＢＳ或者ＣＳ程序一样，接口的工作是基于驱动的，这个驱动是一个请求。根据这一特征，我将参与数据交互的系统划分为客户端和服务端。很显然，客户端是发起请求的，服务端是接受请求，处理请求，响应数据的。

　　最原本的接口讲到这里应该算是结束了。可是在实际上，接口却并非这么简单。

　　客户端和服务端的定位，虽然说在软件世界里，对于接口谁做客户端，谁做服务端是均可实现的，但能实现并不表示合理。我们做软件，做解决方案不仅仅只是要求实现某功能。我们追求系统的合理性，更高的性能，跟切近现实的模型等原则。对于谁做客户端谁做服务端，我举个例子。我是个宅男，周末基本不出门，某天，我给一个脑残的老板打电话叫外卖要了一份‘青椒肉丝面’，最后老板给我送来的有‘红烧牛肉面’，‘兰州拉面’…………等数以百计的品种，让我找出我叫的外卖。很明显是吧，现实生活中没人这么做是吧。在回头对比接口中的服务端和客户端。作为数据的提供者，那你天生就是做客户端的，别的系统给你个请求，你得将请求数据处理好了给客户端，可是你不乐意了，不想做数据处理，好吧，你要争着做客户端，一股脑的把自己有的同类数据全给了应该做客户端而没做成的服务端。请问这跟那个脑残的外卖老板有区别吗？

　　结论一：系统间的接口开发，要遵循这样一个原则，谁是数据提供者，谁就是服务端。

　　实际开发中，其实也有很多要注意的地方，举例说明。

　　１.能不能在开发前，尽量将所需数据要素考虑充分一点，我们可以接受有变化，但不是接受无休止的变来变去。

　　２.数据格式能不能选择一个通用一点的，既然是不同系统的数据交互，可能我是ｊａｖａ，你是ｖｂ，他是ｃ等等。你给我的类型是个ｊａｖａ没有的，我给你的是ｃ和ｖｂ没有的类型，转换起来不复杂吗？举个实际的例子，你就说这数据类型Ｄａｔｅ吧，还都是在ｊａｖａ系统互相交互，你给我个ｊａｖａ．ｓｑｌ．ｄａｔｅ包下的数据，亲，你知道就你这样给处理会很麻烦知道吗？所以在数据格式的定位上要遵从普遍性。可能非软件人员看你倒腾的越复杂觉得你越牛逼。可是大家都是做软件的，都知道是怎么回事，没必要装。

　　３.接受到的数据要做校验。咋我的系统中，也许人民币是用ＲＭＢ表示，接受数据中给我的表示人民币的代号是＃＠￥＠，你说如果这样的数据你不做校验和转换你拿去有什么用。天知道这代表什么。

　　４.一定要有Ｌｏｇ日志，这是日常维护的必须手册。同时，也是今后系统间出现重大问题后你的救(敏感词分开写)命稻草，能够划清责任。这个问题我在系统联调上感觉真的是太有作用了，别人发一个请求，然后看到一个相应超时，！＠＃￥￥％＠＃￥＃￥％跟我说，你那边怎么这么多问题，我怀着上坟的心情去看Ｌｏｇ，＃＠％￥＃＠，坑爹是吧，你请求都没发到我机器上！！！！

　　另外，在某项目开发中，我遇到一个很不爽的问题，信贷和票据做接口，核心跑来插一杆子。虽然，虽然，你给我做了一个中间处理，在一定程度上为信贷和票据都做了一定的贡献，可是我想说，这跟你有什么关系，还是举外卖的例子，这次那脑残老板不是给我数以百计的品种了，是找了个服务员，我叫了个肉丸，服务员给我捅成肉沫送来了。请问是我不能将肉丸嚼成肉沫还是怎么的，是我这边不能处理数据吗？莫名其妙！

　　做事要有个原则，否则做出来的东西，那就是个四不像。不依规矩，不成方圆。

呵呵。 接口的日志 处理也很重要
那么多日志 你放文件 你放数据库 日志多 了你怎么处理

文件的  每天一个文件，日期格式命名！

额？没人交流下自己项目上遇到的情况吗？