为什么很多第三方接口,都改成了基于http,直接传递json数据的方式来代替webservice?

testcpast
  • 708

曾经不同系统间交互问题时,总是优先考虑webserivce,现在看到除了一些老牌的公司,比如amazonk对众的接口还是webservice的方式,其他很多国内新项目的接口都开始转向直接传json的方式。我知道的优势之一,就是webservice的消息体肯定比json这种方式要大。请问,除此之外,设计这些对众接口的时候,还有什么其他的考虑吗?

回复
阅读 49.9k
12 个回答

你这实际上是三个问题,从WebService到今天流行的RESTful API(JSON) over HTTP,经历了数次变革

1 WebService有很多协议,为什么HTTP比较流行?

WebService是个很重型的规范,它的应用协议是SOAP(简单对象访问协议),它所依赖的下层通信方式不单单是HTTP,也有SOAP over SMTP, SOAP over TCP,由于HTTP协议群众基础广,开发调试方便,所以,成了WebService中最为流行的方式。

甚至很多公司在内网通信,也用HTTP来做,比如,应用调用搜索引擎,Solr就是一个例子。

但HTTP也是TCP上性能比较差的协议,因为HTTP是基于TCP的,有3次握手,再加上HTTP是个文本传输协议(虽然也可以传二进制的附件,但业务逻辑还是文本用的多),又有很多复杂的HEADER。所以人们发明了一些更高效的通信协议来做远程调用,比如ACE、ICE、Corba、淘宝的HSF,但这是后话了,不展开细说。你只要知道,HTTP之所以流行,乃是简单易用群众基础广的结果。

2 WebService为什么不如RESTful API流行

WebService诞生十几年了,最初是IBM、微软比较热心在推,一直也不温不火。倒是XML-RPC, RESTful以及比RESTful还要简陋的远程调用方式后来居上。感觉是不是有点像民间的Spring干掉官方的EJB?

究其原因,还是WebService实在太笨重了,SOAP信封犹如婆娘的裹脚布,又臭又长,广大开发人员是叔可忍嫂不能忍,于是就有了简化版的,叫XML-RPC,后来伴随着Web2.0流行,RESTful独领风骚。我在10年前做过一个产品,纯PHP+JS,标准的WebService,连WSDL我都要专门写个PHP程序来生成,还好只是我一个人开发,要是团队协作,我早就被骂得不成人形了。

再后来,连RESTful都被嫌弃了,大伙儿干脆连PUT、DELETE都懒得用,直接用GET和POST。

同时,我得说,这只是在互联网领域,大部分企业的业务逻辑相对简单,同时工期又变态的短(就像大部分互联网创业公司用糙快猛的PHP,而不用相对严谨的Java一样)。在某些业务复杂,稳定性和正确性要求高的领域(如ERP、电商、支付),WebService还有是用武之地的。

3 为什么JSON比XML流行

还是易用性,JSON的可读性比XML强几条长安街,解析规则也简单许多。XML解析的时候规则太多了,动不动就非法字符,动不动就抛异常。这对追求高开发速度和低开发门槛的企业来说,是个致命伤。

JSON的缺点是数据类型支持较少,且不精确。比方说:

price:12580

在json里,你无法知道这个价格是int, float还是double。

所以,如上面第二条所述,在一些业务要求较高的领域,还是XML更合适。

最后说一下性能,JSON的性能高于XML,除此之外,基于XML和HTTP的WebService, 基于JSON的RESTful API,并没有性能差异。

XML性能糟糕到什么地步呢,有一种专门的CPU叫做XML Accelerator,专门为XML解析提供硬件加速。

JSON确实是一种很好的交换数据结构。
除了这个之外,javascript原生支持json解析,且解析起来很简单。这个很重要,因为http接口大部分是给页面的Javascript解析使用的。然后为了保持一套接口,app代码也使用这个json接口。所以就流行了起来。

秀能
  • 2
新手上路,请多包涵

json解析比较简单,在js或者php很容易就可以解析成对象,易于操作

用过Web Service,感觉:
过于复杂庞大,通过xml来传数据的方式导致大量的验证、类型分析、异常处理,性能损耗很大,并且开发也过于复杂。xml相关的库也很大,部署成问题。
而其提供的所谓“自动发现”也由于复杂等等原因很难使用;安全性也非常复杂,各种语言、框架的实现想要兼容
也要费一番力气。

面向一般开发者的API,显然应该考虑简单易用。而且公开到Web环境中,性能也很重要。JSON这种适应性超强的格式受欢迎也就很正常了。

编程语言对json的自然支持也是一个原因。比如json字符串可以自然的变成javascript对象操作,反过来也一样。

高科技企业家
  • 2
新手上路,请多包涵

REST就是答案

个人经验来说吧,WebService 很复杂,调用庞大,哪怕像是 .net 这种原生提供相关支持库的工具用起来也多少力不从心,而且 XML 人手阅读哪怕有语法高亮也是吃力,姑不论效率问题了。

JSON 相比之下轻量得多,可谓简陋,但容易阅读许多原生不支持 WebService 的语言和工具都提供了 JSON 支持。简单的语法也带来了更好的效率。

前面有人提到类型系统的问题。XML 是强类型的,在整个解析过程中很多时间都被花在类型检测上了;JSON 则是弱类型,完全依赖两端代码共同遵守同一界面合约(contract)来保障。前者适合于存在按类型检索重载的场合,一般适用于 CXX、C#、Java 这类强类型的语言;而后者则更适用于 Javascript、Python、Objective-C 这类弱类型语言。

不过 JSON 也并非不可指定类型。通过合理的上层协议便可实现,再不需要与 Javascript 直通的时候也可以对语法小修改来实现。举例:

MTSession {
    id: MongoIdentifier {
        id: "1225…"
    },
    uid: 2024,
    flags: /* Dictionary */ {
        authSaved: true,
    }
}
LiddleFang
  • 3
新手上路,请多包涵

異質系統的通訊中只關心兩個問題

物件模型以及資料

Web Service使用的SOAP可以自描述物件模型
可是使用xml來傳遞資料實在是耗費太多資源了

這個時候,JSON的輕量優點就突顯出來
至於物件模型
你都要用我的服務,看一下文件不過份吧

我觉得两个原因,rest最开始是为页面服务的。js原生支持json,同时json是kv型数据,用nosql更好

webservice?没听说过
我就知道json

你知道吗?

宣传栏