去年做的一个项目要与SAP的ERP系统做20来个webservice接口，有服务端的，有客户端的，一开始，已经明确的5个接口是分别单独开发的，各自制定了冗长的数据字典和接口规范，并在后面阶段的上线测试过程中，一次又一次的更新接口，大都是合同类的数据接口，基本上一个接口就40~70个字段，对方字段命名及其晦涩与低可读性，而合同处理又不能有闪失，令我及其郁闷。
后来，在多次沟通后，为后续接口制定了一套标准，即一个接口，多套业务，接口参数传入业务处理类型，接口内容传递string，由双方各自把数据封装成xml再变成长字符串，这样就解决了接口字段发生变动不会需要接口重新发布与调试，只需要调试业务处理的模块。
这样之后，省下了大量重新部署接口和调试接口的时间，但是随着业务量的上升，接口调用不通的情况开始出现了，并且由于业务较为复杂，接口调用失败的异常处理也成为了接口开发与调试的主要内容，正常模式代码只占有四分之一，各种接口调用出错的回滚机制代码要占用四分之三，并且异常调试也需要非常大量的测试，才能保证每种异常都执行过。
这20来个接口要负荷每天数百上千的调用，业务金额每个月都会过亿，希望iteye的朋友们能给我指一条今后webservice接口开发的明路。无论是资深牛牛还是初学菜鸟，都会非常感谢你们不吝时间给我的建议的
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
