平台对外通用接口设计

[huaer111]

背景
公司正在设计一个基于JavaEE的平台，需要接收各省分中心收集的企业标准数据，各分中心都有自己的系统，考虑使用接口的方式进行数据对接；具体策略是公司对外暴露几个平台通用接口，并提供调用说明，让各分中心自己开发数据报送程序。
说明：
1、企业数据可逐条发送，也可批量发送；
2、企业数据本身就是个集合，比如1家企业对应1条企业基本信息＋n条专业技术人员信息＋n个学历证明等附件；
3、附件可能是图片、PDF、WORD，每个附件要求最大10M，1个企业会有n个附件；
4、数据量级不算特别的大、频率较低，大概几百家企业、每周同步一次；
5、数据传输要保证安全、可靠。

本人技术水平不高，用百度、论坛等各种方式进行了学习（时间有限），但要撰写一个通用接口说明文档还是觉得欠缺，望各位大神能给出一些参考建议，我先说一下我初步的想法。
支持的数据对接方式有两种：
一个是让各分中心把数据整合到标准Excel模板中，然后使用公司指定的账号登录平台并上传，然后公司通过人工进行数据审核、校正、整理入库（也考虑写个解析excel的程序，担心）；这个比较LOW，整体效率也比较低，但难度最小，可以在初期做个过渡。
另一个是对外发布一系列WebService接口，结构化数据（比如企业基本信息、专业技术人员信息等）用SOAP方式通过WebService发送过来，附件信息用流的方式发送过来；接口收到数据后入库，并反馈入库是否成功。在报文中，要求各中心增加一个发送方ID号（事先给他们），用来识别发送方是谁。

现在的问题是本人技术水平有限、对此也不太自信，比如用WebService靠谱吗，是不是用其他方式更好？另外对很多技术细节，比如安全、传输等方面只是简单了解；还有非常重要的一点，技术文档必须体现哪些方面，才能让阅读者尽可能清楚的了解怎么进行技术对接？

在此提前谢过各位经验丰富的朋友，望能多多指教，感激不尽。

[Defonds]

你的场景用 web service 是可以的，或者说比其他方案要好。 至于 rest 还是 soap，得看你的业务类型了，一般来讲互联网之类的 rest 比较合适，这个不多说，最近炒的很火热，相关资料一搜一大堆；而如果是企业级尤其是金融类应用建议还是 soap，因为 soap 具备以下 rest 所不具备的特性： 1、支持增加很多企业级安全特性的 WS-Security 2、rest 受限于 http，http 本身无法提供两阶段提交分布式事务资源，但是 soap 可以 3、soap 保证消息可靠性，而 rest 不具备一个标准的消息体系(这点对于支付领域至关重要) 这些问题其实应该是架构的工作范畴了。更多资料可以参考： http://blog.csdn.net/defonds/article/category/1092593