对外接口注意点

在公司一直在做一些 对外接口的 项目，包括rest、hession、webservice、ice等类型API。在项目的 重构 和 优化过程中，发现对外暴露的接口主要存在的问题和改进方案总结如下：

 

（１）、接口的异常处理：对外暴露的接口，都是采用远程调用的方式访问，建议都不要显式地抛出异常 ，其原因有主要有两点 : 一是调用方捕获不到这些异常，其次去捕获这些异常也肯定消耗很多网络带宽，有些得不偿失。如果一定要处理异常信息，建议在接口实现里把异常都处理掉，需要提示给调用者的，返回错误标识，比如用不同的整数值表示各种错误，这样调用者即可根据错误标识来继续处理业务。

 

（２）、关于参数校验：远程接口传入的参数，尽量都要进行校验 ，这样一方面可以避免发生各种由于参数不合法而引起的运行时异常，同时还可以给调用者以明确的提示。但是，如何校验参数，其实也还是有些要注意的。在项目里发现一些实现里使用断言机制校验参数，结果运行时参数不合格就直接返回了 IllegalArgumentException 异常，这样做结果引起系统因为调用参数不合格而打印的没有什么实际价值的日志信息越来越多，而且调用方也捕获不到异常，调用者还不知道出错原因。建议直接编码来验证参数，不合格时返回错误标识；还有就是参数校验的顺序，建议根据出错的概率和验证参数的难易程度来顺序校验参数，对于那些复杂的（比如要查询数据库进行校验）校验逻辑放在比较容易验证的参数后面，其好处不言而喻了。

 

（３）、返回结果：在 相关API 项目里目前大都用 XXXResult 名称格式的类来包装错误标识值和结果信息，都是非常好的模式。但是对于 Rest 风格的接口，结果发现返回的 XML 结果几乎没有统一的规范 ， 如果有使用过支付宝接口的开发者应该注意到，支付宝接口的返回结果就定义的非常规范和统一，包括错误表示、结果信息、请求参数、签名机制等都有详细的定义，同时每个接口返回的 XML 数据格式都是一致的，让调用者查看和处理结果都非常清晰。

 

（４）、关于性能：目前，大多数 API 项目 都是采用某种支持 框架来对外暴露接口 。其实，每种框架都有其适用性和局限性，怎么合理应用框架真的很重要的，在优化的过程，就发现接口实现实际上耗用的时间非常少，大部分时间都去构造接口实现对象去了。对于性能优化，其实有很多思想和模式可讨论，主要想说的几点就是：关键是要发现瓶颈 ，把代码逻辑分解开来，跟踪每段代码的执行，查看堆栈都是不错的手段；其次是可以根据业务情况，进行业务上的优化也非常不错 ，比如有些实时性要求不高的业务逻辑可以异步处理等等；还有的就是一些技巧方面，包括使用缓存，把执行结果缓存起来，多线程同时处理计算结果等。

 

注：该文章于08年12月在公司内部分享的，希望给大家有所帮助。