没有做过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的存在，导致它的请求和响应都是格式、类型严格的，总线或者其他服务消费者容易预先知道会是什么样子的请求和响应。
1 回答
Cats萌萌
TA贡献1805条经验 获得超9个赞
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以资源的方式来抽象。点到即止吧，实在没力气长篇大论了……
添加回答
举报
0/150
提交
取消