散文精选网网友提问：
既然有
优质回答：
楼主会有这样的问题显然是因为只看到了现状而忽略了这两种方式的历史发展。
其实这个问题倒过来问可能会比较合适。
既然有了RPC请求为什么还需要HTTP呢？
RPC早在上世纪80年代就被人用来做分布式系统的通信，Java更是在早期的1.1版本就提供了Java版本的RPC框架（RMI）。
而HTTP协议则是1990年才开始作为主流协议出现，而且HTTP发明的场景是用于web架构。所以在很长一段时间内，HTTP只是用于浏览器程序和后端web系统通信用的东西，而HTML几乎是唯一的数据支持格式。如此笨重的HTML，没有人会考虑使用HTTP作为分布式系统通信的协议。在很长一段时间内，RPC才是正统。
然而随着前端技术的发展，AJAX技术和JSON的大行其道，HTTP调用慢慢脱离了HTML，转而使用JSON，这才为后面用于系统间调用定下基础。
最后随着RESTFUL思潮的兴起，越来越多系统考虑用HTTP来提供服务，但这时候，RPC已经是各种大型分布式调用的标配了。
所以从历史的进程来看，我们发现HTTP是后来者是追赶着，这个市场一直是被RPC霸占着的。
那么回到题主的问题，那既然现在有了HTTP这么方便的技术，是不是我们就可以把RPC一脚踢开了？
不可否认，HTTP方式的沟通，给程序员们提供了大量便利。因为现在大部分的系统都是面向浏览器的（很多手机app也是使用HTML5来渲染的），因此使用HTTP协议，能够保证系统间最大程度的技术栈一致，那无疑是维护成本最低的，而这时HTTP的技术生态也刚好满足这个条件，所以燎原之势一触即发。
但是总是有部分系统，他们需要使用RPC，一可能是老架构，也不敢动这块，二是性能要求可能只有RPC可以满足。不过个人觉得现在的HTTP2的多路通信已经对性能有了很大的提升，所以不是非常苛求性能的话，HTTP应该能够满足大部分需求。
其他网友回答
首先：
http 和 rpc 并不是一个并行概念。
http是超文本传输协议，应用层网络协议。
rpc不是协议，是指remote procedure call 远程过程调用，对不同应用间相互调用的一种描述。其调用协议通常包含传输协议和编码协议；支持http和tcp；
其次：
rpc调用是面向服务的封装，针对服务的可用性和效率等都做了优化。单纯使用http调用则缺少了这些特性。
例如rpc框架提供的负载均衡，服务治理，自动熔断/降级，实现二进制传输等；
如果把一个http server容器上封装一层服务发现和函数代理调用，那它就已经可以做一个rpc框架了。
总结：
RPC是一种编程模式，把对服务器的调用抽象为过程调用，通常伴随着框架代码自动生成等功能。使用RPC做网络服务开发时，通常只需要实现服务器端的一个处理函数，其余的客户端调用，序列化反序列化，方法派发等都由框架或者生成的代码来完成，较大地减轻了网络服务开发和调用的复杂性。RPC框架更多的在内网中应用间调用使用，http 除了内网传输，更习惯用在跨网间，跨语言间调用。
其他网友回答
现在确实用http了，rpc就像是dubbo时代，http就像springcloud时代，总之技术无好坏，关键看怎么实现
其他网友回答
效率
