WEB开发中,使用JSON-RPC好,还是RESTful API好
1个回答
展开全部
JSON-RPC比RESTful API好很多。
======
我厌恶restful API如同我厌恶OOP;但与其说我厌恶restful,倒不如说我厌恶鼓吹restful API的一些伪·程序员。
很多鼓吹restful API的程序员,实际上并不理解restful的设计理念,纯粹是在人言亦言,随便看了几篇网文在说restful,自己便也更着鼓吹。
做为一个合格的技术人员,最基础的要求是要对自己所使用的技术有了解,明白各种技术的适用场景,然后因地制宜。
restful首先是要求必须把所有的应用定义成为“resource”,然后只能针对资源做有限的四种操作。
这是对API一个非常糟糕的抽象,有太多现实中需要的API,无法顺当的融入到restful所定义的规范中。
比方说,user login / resetpassword等等。
restful的信徒,他们会说可以根据这个那个规范,把login / password等也纳入为某种资源,然后进行增删改查。这在我看来,纯粹是在解决一些原本不存在,根本不需要解决的问题,纯浪费。
所有的接口,服务器端原本就存在有相应的函数,它们本来就有自身的命名空间,接受的参数、返回值、异常等等。
采用轻便的方式暴露出来即可。
无需把一堆函数重新归纳到“资源”,再削减脑袋把所有的操作都映射为“增删改查”。
对应到web上,rpc的成熟方案非常多,有古老的soap,也有轻量的json rpc。
JSON rpc基本上仅是要求所有的请求必须有msg id,有函数名,然后可定义参数,并且区分返回值与异常;也可定义『命名空间』来对函数模块做划分。
这与大多数语言的模块、函数定义相符,使用起来是非常便利的。
很多json rpc是供web前端ajax调用,若前端调用抽象得当,调用远程API,实际上与调用本地函数无甚区别。
实际上,json rpc也未必需要跟http绑定,即便是在web上,它也可以走web socket,这样子,前端可以使用同一web socket管道批量发送请求,而服务器端乱序返回结果时,前端也可以根据msg id做准确的回调。
websocket,批量调用,乱序返回,这些都可以显著提高API的输出吞吐,这些是在json rpc的设计考量内。
调用更方便,性能也更好,两全其美是完全可能的。
想当然的为了“快”,为了“简单”就必须牺牲别的,这是严重的思维误区。
有些方案,纯粹就是糟糕的方案。
restful API仅适用与业务非常简单的场景,比方说,就是为了提供少量数据表单的增删改查。而这种场景实在是太过简单,实际中几乎找不到。
======
我厌恶restful API如同我厌恶OOP;但与其说我厌恶restful,倒不如说我厌恶鼓吹restful API的一些伪·程序员。
很多鼓吹restful API的程序员,实际上并不理解restful的设计理念,纯粹是在人言亦言,随便看了几篇网文在说restful,自己便也更着鼓吹。
做为一个合格的技术人员,最基础的要求是要对自己所使用的技术有了解,明白各种技术的适用场景,然后因地制宜。
restful首先是要求必须把所有的应用定义成为“resource”,然后只能针对资源做有限的四种操作。
这是对API一个非常糟糕的抽象,有太多现实中需要的API,无法顺当的融入到restful所定义的规范中。
比方说,user login / resetpassword等等。
restful的信徒,他们会说可以根据这个那个规范,把login / password等也纳入为某种资源,然后进行增删改查。这在我看来,纯粹是在解决一些原本不存在,根本不需要解决的问题,纯浪费。
所有的接口,服务器端原本就存在有相应的函数,它们本来就有自身的命名空间,接受的参数、返回值、异常等等。
采用轻便的方式暴露出来即可。
无需把一堆函数重新归纳到“资源”,再削减脑袋把所有的操作都映射为“增删改查”。
对应到web上,rpc的成熟方案非常多,有古老的soap,也有轻量的json rpc。
JSON rpc基本上仅是要求所有的请求必须有msg id,有函数名,然后可定义参数,并且区分返回值与异常;也可定义『命名空间』来对函数模块做划分。
这与大多数语言的模块、函数定义相符,使用起来是非常便利的。
很多json rpc是供web前端ajax调用,若前端调用抽象得当,调用远程API,实际上与调用本地函数无甚区别。
实际上,json rpc也未必需要跟http绑定,即便是在web上,它也可以走web socket,这样子,前端可以使用同一web socket管道批量发送请求,而服务器端乱序返回结果时,前端也可以根据msg id做准确的回调。
websocket,批量调用,乱序返回,这些都可以显著提高API的输出吞吐,这些是在json rpc的设计考量内。
调用更方便,性能也更好,两全其美是完全可能的。
想当然的为了“快”,为了“简单”就必须牺牲别的,这是严重的思维误区。
有些方案,纯粹就是糟糕的方案。
restful API仅适用与业务非常简单的场景,比方说,就是为了提供少量数据表单的增删改查。而这种场景实在是太过简单,实际中几乎找不到。
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询