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