没有做过 web service 下面全是本人臆断，莫笑。
用 SOAP 做 web service 最后调用的方法不也是基于http的么，和咱们现在调用的restful 的 api 接口有什么优势呢？
又是需要装扩展，又是需要WSDL文件,这岂不是很麻烦？
下面是我一位朋友给我的解答，但是我觉得我很难看懂，希望解释简单些和补充
RESTful 的接口非常方便易用。但是有一种场景：企业应用之间的集成，比如说 A 系统上行数据到总线有 10 个字段，而 B 系统只关心其中的 5 个字段，如果采用 Web Service 的方式，就是 XML 的数据封装，就可以在总线上完成 XSLT，只给 B 系统 5 个字段。此时，XML 相对 JSON 是有优势的。这是在实际使用场景中的一个情况。
如果说，使用 RESTful + XML 行不行？行，肯定没问题。但是 RESTful 的服务通常不采用 XML。 另外， Web Service 因为有 WSDL 的存在，导致它的请求和响应都是格式、类型严格的，总线或者其他服务消费者容易预先知道会是什么样子的请求和响应。
XML、JAVA、SOAP这种组合一起出现的比较多，太重了，性能差，开发效率低。
轻量级的就用RESTful, 基本上SOAP能实现的功能，REST也都能实现，你要啥格式有啥格式。SOAP我只遇到过两次，都是在单点登录的时候调用别人的接口。
大神朋友的说法有问题
RESTful 的接口非常方便易用。但是有一种场景：企业应用之间的集成，比如说 A 系统上行数据到总线有 10 个字段，而 B 系统只关心其中的 5 个字段，如果采用 Web Service 的方式，就是 XML 的数据封装，就可以在总线上完成 XSLT，只给 B 系统 5 个字段。此时，XML 相对 JSON 是有优势的。这是在实际使用场景中的一个情况。
RESTful的方式也仍然可以达到这样的目的，以这样的场景论据得出“XML 相对 JSON 是有优势的”的结论是很扯的。
事实上RESTful仅仅是一种架构风格，对响应格式及结果没有啥束缚。
如果说，使用 RESTful + XML 行不行？行，肯定没问题。但是 RESTful 的服务通常不采用 XML。 另外， Web Service 因为有 WSDL 的存在，导致它的请求和响应都是格式、类型严格的，总线或者其他服务消费者容易预先知道会是什么样子的请求和响应。
从格式约束的角度来说，XML的确是要比JSON严谨一些。如何取舍就好比经典的关系式数据库和NoSQL的取舍一样，看实际情况了。
再次强调，RESTful仅仅是一种架构风格，至于响应格式是用JSON还是XML是另外一个层面的事情。
回到SOAP和RESTful的对比上来，我认为最大的不同是抽象方式的差异，SOAP以过程和事务来抽象，RESTful以资源的方式来抽象。
点到即止吧，实在没力气长篇大论了……
用SOAP是因为系统够复杂，且有中间件吧（我是做中间件的，笑），一般针对对象是巨型系统，或者复杂的多系统整合。这样Service A开发跟Service B要联动时，开发A的公司和开发B的公司，一家拿出一个WSDL就好了。
比如我在做的是某国外航空公司的项目。
公司内有货物管理，人员管理，航班信息，财务系统，等等，有新开发或现存老系统10多个，因为复杂，这些Service间的访问需要中间件（ESB）来控制。同时此航空公司若加入类似亚洲星空联盟这样的组织，各个不同公司间的Service互相访问（比如日航航班出问题，要给你安排到美西北航空的空席去）也需要ESB来控制，每个service都统一用SOAP。这次欧洲的某公司要玩互动，对应下ESB，给他个WSDL就好了。