关于 SOAP 做 web service 的困惑

Question

没有做过webservice下面全是本人臆断，莫笑。
用SOAP做webservice最后调用的方法不也是基于http的么，和咱们现在调用的restful的api接口有什么优势呢？
又是需要装扩展，又是需要WSDL文件,这岂不是很麻烦？
下面是我一位朋友给我的解答，但是我觉得我很难看懂，希望解释简单些和补充
RESTful的接口非常方便易用。但是有一种场景：企业应用之间的集成，比如说A系统上行数据到总线有10个字段，而B系统只关心其中的5个字段，如果采用WebService的方式，就是XML的数据封装，就可以在总线上完成XSLT，只给B系统5个字段。此时，XML相对JSON是有优势的。这是在实际使用场景中的一个情况。
如果说，使用RESTful+XML行不行？行，肯定没问题。但是RESTful的服务通常不采用XML。另外，WebService因为有WSDL的存在，导致它的请求和响应都是格式、类型严格的，总线或者其他服务消费者容易预先知道会是什么样子的请求和响应。

Answer 1

大神朋友的说法有问题RESTful的接口非常方便易用。但是有一种场景：企业应用之间的集成，比如说A系统上行数据到总线有10个字段，而B系统只关心其中的5个字段，如果采用WebService的方式，就是XML的数据封装，就可以在总线上完成XSLT，只给B系统5个字段。此时，XML相对JSON是有优势的。这是在实际使用场景中的一个情况。RESTful的方式也仍然可以达到这样的目的，以这样的场景论据得出“XML相对JSON是有优势的”的结论是很扯的。事实上RESTful仅仅是一种架构风格，对响应格式及结果没有啥束缚。如果说，使用RESTful+XML行不行？行，肯定没问题。但是RESTful的服务通常不采用XML。另外，WebService因为有WSDL的存在，导致它的请求和响应都是格式、类型严格的，总线或者其他服务消费者容易预先知道会是什么样子的请求和响应。从格式约束的角度来说，XML的确是要比JSON严谨一些。如何取舍就好比经典的关系式数据库和NoSQL的取舍一样，看实际情况了。再次强调，RESTful仅仅是一种架构风格，至于响应格式是用JSON还是XML是另外一个层面的事情。回到SOAP和RESTful的对比上来，我认为最大的不同是抽象方式的差异，SOAP以过程和事务来抽象，RESTful以资源的方式来抽象。点到即止吧，实在没力气长篇大论了……

Answer 2

用SOAP是因为系统够复杂，且有中间件吧（我是做中间件的，笑），一般针对对象是巨型系统，或者复杂的多系统整合。这样ServiceA开发跟ServiceB要联动时，开发A的公司和开发B的公司，一家拿出一个WSDL就好了。比如我在做的是某国外航空公司的项目。公司内有货物管理，人员管理，航班信息，财务系统，等等，有新开发或现存老系统10多个，因为复杂，这些Service间的访问需要中间件（ESB）来控制。同时此航空公司若加入类似亚洲星空联盟这样的组织，各个不同公司间的Service互相访问（比如日航航班出问题，要给你安排到美西北航空的空席去）也需要ESB来控制，每个service都统一用SOAP。这次欧洲的某公司要玩互动，对应下ESB，给他个WSDL就好了。