RESTful
RESTFUL是一种网络应用程序的设计风格和开发方式，基于HTTP，可以使用XML格式定义或JSON格式定义。RESTFUL适用于移动互联网厂商作为业务使能接口的场景，实现第三方OTT调用移动网络资源的功能，动作类型为新增、变更、删除所调用资源。?
HTTP
http是一个简单的请求-响应协议，它通常运行在TCP之上。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。请求和响应消息的头以ASCII码形式给出；而消息内容则具有一个类似MIME的格式。这个简单模型是早期Web成功的有功之臣，因为它使得开发和部署是那么的直截了当。?
RPC
RPC是远程过程调用（Remote Procedure Call）的缩写形式。SAP系统RPC调用的原理其实很简单，有一些类似于三层构架的C/S系统，第三方的客户程序通过接口调用SAP内部的标准或自定义函数，获得函数返回的数据进行处理后显示或打印。
https://baike.baidu.com/item/远程过程调用/7854346?fromtitle=RPC&fromid=609861&fr=
对比
RESTful基于HTTP,所以RPC与HTTP对比就等于RPC与RESTful对比。
RPC与RESTful
先科普一下
REST 和 RESTful 什么区别？
REST（Representational State Transfer）：表现层状态转移，一种软件架构风格，不是标准。既然不是标准，我可以遵守，也可以不遵守！！！
什么是表现层状态转移：
? Representational （表现层）
? State Transfer（状态转移）：通过HTTP动词实现。
总结：URL定位资源，通过Http动词去操作URL标识的资源(get(获取),pst(添加),put(更新),delete(删除))。
什么是RESTful
? 基于REST构建的API就是Restful风格。
http vs 高性能二进制协议
http相对更规范，更标准，更通用，无论哪种语言都支持http协议。如果你是对外开放API，例如开放平台，外部的编程语言多种多样，你无法拒绝对每种语言的支持，相应的，如果采用http，无疑在你实现SDK之前，支持了所有语言，所以，现在开源中间件，基本最先支持的几个协议都包含RESTful。
RPC协议性能要高的多，例如Protobuf、Thrift、Kyro等，（如果算上序列化）吞吐量大概能达到http的二倍。响应时间也更为出色。千万不要小看这点性能损耗，公认的，微服务做的比较好的，例如，netflix、阿里，曾经都传出过为了提升性能而合并服务。如果是交付型的项目，性能更为重要，因为你卖给客户往往靠的就是性能上微弱的优势。
RESTful的规范到底是不是鸡肋？
我认为，微服务的盛行，开放平台的盛行，的确让RESTful过于“流行”了。你可以看看，无论是Google、Amazon、netflix（据说很可能转向grpc），还是阿里，实际上内部都是采用性能更高的RPC方式。而对外开放的才是RESTful。
如果你的应用非常简单，无论用哪种都无所谓了，基本都能满足要求。
关于无状态、幂等
这个跟你是否采用RESTful无关，主要还是看接口内部实现，所以，把这个作为RESTful优点的可以闭嘴了。
安全性
显然，基于Http更安全一些，默认80端口，防火墙友好。
RESTful也分为严格的和自由的
RESTful还有个好处是制定了一系列规范，但是大多数使用者都是自由风格的，根本不是严格按照RESTful规范实现。当然存在就是道理，这样做更高效，但是不够通用。
无疑，严格按照资源抽象，API看起来更清晰，更容易被大家理解。同时，开发人员的复杂度也更高。
最后建议
对外开放给全世界的API推荐采用RESTful，是否严格按照规范是一个要权衡的问题。要综合成本、稳定性、易用性、业务场景等等多种因素。
内部调用推荐采用RPC方式。当然不能一概而论，还要看具体的业务场景。
另外一个因素是人，关键是你有什么人，postgresql、mysql都有用的不错的，迁来迁去，关键是你的人对哪个更熟悉。
不能为了用RESTful而用RESTful。
RPC的思想是把本地函数映射到API，也就是说一个API对应的是一个function，我本地有一个getAllUsers，远程也能通过某种约定的协议来调用这个getAllUsers。至于这个协议是Socket、是HTTP还是别的什么并不重要；
RPC中的主体都是动作，是个动词，表示我要做什么。
而REST则不然，它的URL主体是资源，是个名词。而且也仅支持HTTP协议，规定了使用HTTP Method表达本次要做的动作，类型一般也不超过那四五种。这些动作表达了对资源仅有的几种转化方式。
