前端为什么基本上都使用 AJAX 请求，而不使用 RPC？

[zacharyjia]

前两天试了一下 blazor，在 server-side 模式的时候，使用了 SignalR 传输数据。这样可以做到在页面里调用数据的时候，就像调用本地函数一样，而不用自己处理 http 请求，感觉写起来很简单省事儿了。

后面就想到，为什么现在前端基本上都是基于 ajax 做数据刷新，为什么不能使用 rpc 的方式呢？这样的话，一套接口写好，前端后端都可以自动生成对应的函数接口，直接调用多简单？特别是对于很多个人项目来说，不需要手动处理各种 http 请求了，不是更方便吗？实际传输可以基于 ajax 也可以走 websocket，可以做成库帮我们处理，岂不是更省心省力了？

那么这种方式为什么没有推广呢？有什么非常致命的缺点吗？

[lhx2008]

我不是前端，理论上没什么问题，RPC 本质是 stub 的封装，所以前端应该也是可以实现的，至于是 TCP 还是 HTTP 和 RPC 又没啥关系

[zacharyjia]

@rrfeng ok，可能我的题目表述有问题。我之前考虑过说 http 请求，但是又考虑到 web 上用的 rpc 也是基于 http 的，因此也没这么用。后面比较清楚的表述应该是像 @otakustay 说的那样，用调用 rpc stub 的方式替代 请求 url+数据的方式。没想到引来这么多嘲讽，怪我自己。

[sailei]

@zacharyjia https://github.com/Dowte/grpc-demo 你自己去看吧

[sailei]

可以简单理解为 http2 base64 压缩版

[cxh116]

Ajax 只是异步的发送 HTTP 请求的一种技术. 而 RP 是 Remote Procedure Call(远程过程调用)的简称.

Ajax 发送的 HTTP 请求就是 RPC 的一种,因为 HTTP 请求参数相当于远程调用的方法参数,而请求返回相当于远程方法的返回.

只是不像正规的 rpc 协议那么规范而已.

为什么不用 RPC 协议?感觉 JSON 一把梭省事.

[BasIrs]

前端为什么基本上都使用 AJAX 请求，而不使用 RPC ？

[woodensail]

因为 ajax 也能做到你所说的把 api 封装成函数。事实上现在一般大型项目已经不可能在 url 到处飞了。基本上都是在 api 层封装为函数。业务层直接调用函数就行。

[chinvo]

AJAX 是 JS 通过浏览器发请求的方式

RPC 是远程过程调用

RPC 需要发请求, 在浏览器中, 可以是通过 AJAX, 也可以通过 websocket, 还可以通过 webrtc

[jin5354]

可能意义不大，因为对前端来说无论是 rpc 还是 ajax 都是要查接口协议然后调用，rpc 无非是封装了一层，如果能把 ts 引入带来接口类型补全能省点事

[zacharyjia]

@woodensail 但是这个封装是手动的吧，rpc 一般都可以通过代码生成器自动实现，不是更简单吗？

[rrfeng]

所以这个问题就回归到了 http 和 rpc 的优缺点上。

http 参数灵活，rpc 调用方便，但是更新麻烦。

非常多的需要服务端数据的 js sdk 封装好了，直接调用方法，你可以认为这就是个 rpc client 的封装，over http 的。

[liuxey]

基础不牢 地动山摇

[Jooooooooo]

http 就是 rpc

你用 http 的时候把负载均衡, 节点注册发现啥的一搞就是一个 rpc 框架

[woodensail]

@zacharyjia
我能理解你的意思，早年间我也也用过.net 的技术，.net 的开发确实是前后端高度整合，感觉不像是在开发一个网站而是开发一个本地应用程序。
但实际上这只是组件还高度封装带来的错觉。事实上如果你用一些商用的企业服务开发框架，也能做到类似的体验，说白了，复杂的逻辑都只是被人封装了而已，不是不存在。而且这种封装还会带来前后端高度耦合的副作用。
所以现在前端更倾向于自己封装 api，反正一个接口就一行，也不麻烦。

[Soar360]

http://ing.coderbusy.com/

[ysmood]

引用一个标准 rest 库不就可以不手动写了吗？ http with url 本身就是一种 rpc 啊，ajax 符合一切 rpc 要完成的事，只不过 function name 现在是 url path name 了，params 换成 query 或者 post body 了，http 的 status 返回码也是有标准错误定义。哪个都很符合 rpc 要完成的事。

所以从问题出发，如果你发现生写 ajax 处理很麻烦，就写个库或者引用别人的轮子将这个步骤抽象掉，问题解决。这个跟 rpc 没有太大关系。rpc 很古老了，对于前端来说也一点不新鲜。

rpc 是在 http 之前就有了，当计算机性能带宽不再是通信瓶颈后，人们选择牺牲性能和带宽来增加协议的可读性，这样你会发现 http debug 只需要截获他的包用文本编辑器就能读懂，这样就衍生了一大批友好的 http 开发和调试工具，这也是 http 能普及的总要原因，而像 grpc 的数据包你是没法人肉读写的，代理更是没法简单根据数据内容优化路由或者缓存。

各有各的好处，没有完美，只在于取舍而已。如今分布式的流行又让 rpc 的一些想法火起来了而已。

[ysmood]

顺便附上个我 4 年前写的库，和一般 rpc 库不同的是你可以一次调用多个函数组合而不用每次都把数据拉到本地处理，相当于你发送了一个脚本到远端去运行，而且这个脚本是安全可控难以注入攻击的： https://github.com/ysmood/nisper

[DOLLOR]

现在的人都把 AJAX 当作 XMLHttpRequest 的代名词了呢，也许是 jQuery 巨大影响带来的误解。

[mazyi]

多看点书啊

前后端分久必合？合久必分？这都是作为一个技术人员应该有的基础思考吧？不然就只能说自己是一个接口仔。

[mazyi]

@otakustay 就这还工程论断，这不就是 jsp ？