REST 和 RESTful 什么区别
REST，即Representational State Transfer的缩写。翻译过来是表现层状态转换。
如果一个架构符合REST原则，就称它为RESTful架构。
Restful架构是基于Http应用层协议的产物，RPC架构是基于TCP传输层协议的产物。RPC架构的吞吐量和执行速度优于Restful。但是没有十全十美的架构，Restful是一种轻量级，跨语言，跨平台的web服务方式，他是一种设计理念，他强调将网络中的一切事物看成资源，对资源的所有的操作方式均定义成“查，插，删，改” 四种方式，向外界暴露API，用来调用，所有的操作都是无状态的。轻量级是什么意思? 简单，所以复杂的大型应用不适合该架构。跨语言和跨平台这两个可以一起解释。因为该架构一般是针对web应用的，不同模块之间利用Rest进行通信，是利用网络协议来通信，中间传输对应的json对象。因此不同模块之间实际上是透明的，只需要利用HTTP协议，从发送端发送到接收端，接收端自己能够解析网络传输的内容即可。这种解析功能，目前能够用到的web编程语言都可以实现。对于资源的操作方式只有四种，因此极其简单，他能够根据对应的网络状态信息，对其进行响应即可。API其实也就是一个一个的url。
RPC架构的全名是远程过程调用。这个东西十分强大，目前已经成为主流开发架构。当时在本科的时候，做的一款大型网络应用就是基于此架构。当时用的是java的DWR框架，现在rpc框架相当多，而且吞吐量巨大，是开发主流。这个玩意，在原来有一个大名鼎鼎的“冲击波病毒”，就是建立在该原理之上。其实我们用起来非常简单，因为整个RPC的原理图如下所示：
其实你从图中可以看出，他主要是四部分组成, Client, ClientStub, Server, Server Stub。当你在客户端调用服务器端程序时，调用的方式和函数名和服务器端的一模一样，这样大大缩短了开发时间和交流成本，只需要在后端给出整个函数名列表和参数列表即可。如何实现这一功能，主要是在ClientStub封装Client的调用需求，然后发送给ServerStub，它进行解析后返回给Server，完成调用实现。这一部分的实现主要是利用软件工程中的动态代理模式，利用代理处理器，根据不同的参数，来分发处理请求。当然这一部分，实际开发中不需要我们实现。我们只需要调用服务器方法即可。
json-rpc解释
接口调用通常包含两个部分，序列化和通信协议。常见的序列化协议包括json、xml、hession、protobuf、thrift、text、bytes等；通信比较流行的是http、soap、websockect，RPC通常基于TCP实现，常用框架例如netty。
RESTful通常采用http+JSON实现。
JSON-RPC是指通信协议采用二进制方式，而不是http，序列化采用JSON的形式。
http vs 高性能二进制协议
http相对更规范，更标准，更通用，无论哪种语言都支持http协议。如果你是对外开放API，例如开放平台，外部的编程语言多种多样，你无法拒绝对每种语言的支持，相应的，如果采用http，无疑在你实现SDK之前，支持了所有语言，所以，现在开源中间件，基本最先支持的几个协议都包含RESTful。
RPC协议性能要高的多，例如Protobuf、Thrift、Kyro等，（如果算上序列化）吞吐量大概能达到http的二倍。响应时间也更为出色。千万不要小看这点性能损耗，公认的，微服务做的比较好的，例如，netflix、阿里，曾经都传出过为了提升性能而合并服务。如果是交付型的项目，性能更为重要，因为你卖给客户往往靠的就是性能上微弱的优势。
对外开放给全世界的API推荐采用RESTful，是否严格按照规范是一个要权衡的问题。要综合成本、稳定性、易用性、业务场景等等多种因素。
内部调用推荐采用RPC方式。当然不能一概而论，还要看具体的业务场景。