在近些年的组织工作中，交会过许多其他子公司的APIUSB，但是USB文件格式没有两个写的较为轻松的，许多这儿叙述不清楚，是缺乏相应的实例。作为两个合作开发交会者，领到这种的API，很少郁闷，没办法，只能针对这些疑问跟圣索弗展开沟通交流确认，更为重要节约双方老龄，所以工作效率较为低落。最近又交会了两家圣索弗API，甚是郁闷，已无能为力聊著，于是决定发表呵呵他们的观点，局限性还请诸位知友喔点拨。
首先归纳呵呵交会的API文件格式中存有的许多难题：
1、两个圣索弗，提供更多三套非独立的API文件格式，每个API中的USB都须要交会
此种API文件格式在前述组织工作中只碰到过一次，是另一家子公司我就不公开了，所以三套API允诺的搜索引擎也不那样，好在验签方式和验签公钥是那样的。
2、USB文件格式是现写的，是第一次交会，此种感觉是两个实验品
此种首度交会的APIUSB文件格式，交会操作过程前述上是帮圣索弗完成试验的操作过程，交会操作过程碰到的难题，不能解决的就调整USB，此种最恼人，之前的交会完稿了可能不行，须要重新写，引致合宪组织工作，无用
3、USB文件格式没有交会完整业务流程
大部分不是很成熟的文件格式，都缺乏交会业务流程表明，这就引致在前述交会操作过程中须要跟圣索弗沟通交流USB交会业务流程，顺序，和USB间的倚赖关系，而不同子公司间技术上的沟通交流，往往是工作效率最低小的
4、USB表头缺乏必要表明和叙述
有许多小子公司会存有这种许多难题，碰到此种文件格式，我一般拒绝交会，会间接要求圣索弗补充完表头表明之后再展开交会。表头意义不明晰，数据不知道是不是用，还是不是展开交会
5、验签准则有表明却不提供更多简单实例
此种API文件格式，假如不给验签实例的话，在交会试验操作过程中很容易出现验签失败的情况。毕竟开发人员水平B100，验签准则那样，写出来的标识符方法论不一定能保证是那样的，这个时候假如拿API中的验签实例校正呵呵他们的亲笔签名标识符，奥尔奈了。当然，有的是好的API文件格式，会间接提供更多各种语言的亲笔签名生成工具类，间接copy提及即可，省却许多合作开发组织工作
6、两个API文件格式，各个USB的验签准则都不那样
交会过的两个小厂，两个API文件格式，有三个验签准则，USB验签两个，模块身份校正两个，模块NSA两个，数据做的是真安全，但是感觉没必要啊
7、表头命名准则不统一
此种设计很恶心，两个对象外层和里层表头，驼峰形式和下划线形式同时存有，OMG，这个USB的实现应该是多个人合作开发实现的吧，才会提供更多此种很LOW的USB表头命名准则吧。
8、缺乏补充表明的问答(Q&A)模块
试验并不会百分百覆盖所有的是场景，在投入生产之后，总会存有许多未知难题，这个时候API上能有相关解释和表明，则能避免在交会结束后打搅圣索弗了，比如权益类充值，客户是不是查询权益到没到账之类的客诉，这一点我是深有体会啊
9、交会试验环境不稳定，缺乏相应试验数据或者试验数据类型不正确
联调大多会使用试验环境，但是试验环境没有试验数据或者试验数据类型跟正式环境数据类型不一致，就会引致试验环境失去它本来的意义了
其他后续有了再补充吧。。。。。。。。。。
1、对外USB文件格式统一，最忌两个交会涉及多个API文件格式
2、文件格式展现形式，可以是在线API、文件形式，个人较为看好在线APIUSB文件格式
3、能提供更多正式和非正式环境，三套环境都有数据
4、补充完整传USB交会业务流程
5、表头命名风格统一，两个API文件格式只使用一种验签准则
6、表头表明和枚举类型可能存有的值列表都尽量提供更多，并补充全部错误码信息
7、提供更多校正准则表明和实例，可以的话提供更多各个语言的亲笔签名生成部分标识符
8、USB允诺方式，POST还是GET，JSON结构体提交还是表单提交 、header信息是否须要特别设置等都须要明确
9、补充表明Q&A环节，将经常碰到的难题罗列归纳，引导接入方客诉处理
个人归纳和观点，欢迎指正
