前言
RESTful
比较简单地说就是，大家请求一样的url（GET方法有一个例外，url中带了一个id），通过不同的请求方法，分别进行不同的操作（CRUD）。
JSON-RPC
JSON-RPC是一个无状态且轻量级的远程过程调用（RPC）传送协议，通过JSON传递内容。远程过程调用意思就是，用函数思维写API，用JSON传值，返回一个JSON。
RESTful的逻辑思维比较难转换
初学coding，比较定式的是函数的思维，考虑的是输入什么、输出什么。而RESTful面向资源的思维在写一些功能的时候就会比较别扭，考虑以下例子：写一个根据uid获取用户信息的接口。
JSON-RPC：输入用户的uid，输出用户的信息
REST：先用POST方法创建一个资源（查询），再GET请求一个资源（刚才创建的查询）
相比之下，REST的一个问题就暴露出来：一定要把所有东西都变成资源，然后再要把对应的操作映射成“增删改查”（HTTP的四个方法）。有时候一些很简单的功能，例如一个登录的功能，使用RESTful的话就会演变成十分复杂的问题，化简为繁没必要。
RESTful 在业务简单、有大量静态资源的情况下有优势
在研究过程中我看到了许多例子，都是用的博客、新闻之类的网站应用举的例子，实际上这些比较共同的特点就是里面有比较多的静态资源，而且业务逻辑相对比较简单，可以用简单的CRUD就能搞定了。那么优势在哪里呢？
例如获取某一篇文章的接口，因为请求某个资源，所以这个接口应该会使用GET方法，在url中直接带上文章的id来获取文章。
比较显而易见的就是，GET请求可以被缓存。意思是，如果有一个人向web服务器GET请求，那么这个请求会被缓存起来，下一个同样的GET的时候，就会从缓存中取出上一次的返回，在高并发场景下缓存的引入能够有效提高性能。如果使用POST JSON的方法，每次web服务器都需要去调用底下的PHP或者Java之类，会增大开销。
另外一个比较细微的地方是，POST实际需要两次TCP，而GET只需要一次。尽管实践证明两种方法在网络良好时差距不大，但或多或少是一个优化的点。
然而考虑另外一个场景：搜索一篇文章。
首先这里缓存的意义就没有那么大了，每个用户输入的关键词可能都会不一样，之前的缓存优势没有了。然后，如果搜索中有多个条件，有可能会超出URL的上限（URL最大长度2048），还可能因为搜索条件中有中文等特殊字符出现编码等问题，且搜索中不能包含敏感信息之类，比较麻烦。可能有人会说，GET也可以在Body里面放JSON呀！标准来说GET应该是没有Body的，对比RESTful追求的“规范”有一些打脸。另外也没有办法解决上限的问题，可以说POST一个JSON可以一劳永逸。
GET？POST？
这个是研究这两个方式的时候衍生出的另一个问题：什么时候用GET？什么时候用POST？
毫无疑问，GET适合获取静态资源，通过QueryString获取参数；而传递JSON、包含敏感信息等应该用POST。但再来看两个我觉得比较经典的、微信开发文档的例子：
getAccessToken
这是一个获取AccessToken的接口，这里就使用了GET的方法，我觉得原因有以下几个
传递的都是ASCII字符，不受GET方法的限制
appid和secret已经是相对乱码，也没有加密的必要
接口的功能比较简单，参数固定
请求的频率会比较高（考虑每次操作都需要这个token，且token比较容易过期）
再看另一个发送消息的接口。
subscribeMessage.send
这个接口就使用了POST的方法（尽管也有一个参数在url中）。分析如下
需要传递的内容较多，且可能有中文、特殊字符等，可能会超出GET的长度和字符限制
这里access_token没有放在json中，而是放在了url里。从功能上看这个放在json和url里都没有问题，可能是为了方便开发，服务端可以直接把前端送过来的json数据直接再传递给微信接口
接口结构比较复杂，而且多变。发送的消息根据模板可以有不一样的结构（每个模板的可以填的空、空的类型之类都不一样）
请求的频率比较低（不一定，不好做判断）
通过这个例子应该比较好理解。
————————————————
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
原文链接：https://blog.csdn.net/weixin_43409309/article/details/105330430
RESTFUL
http://www.ruanyifeng.com/blog/2014/05/restful_api.html
比较简单地说就是，大家请求一样的url（GET方法有一个例外，url中带了一个id），通过不同的请求方法，分别进行不同的操作（CRUD）。
web 应用程序，一般分为前端和后端两个部分。前后端通信通常需要一种统一机制，以方便不同的前端设备与后端进行通信。这种需求导致了 API 构架的流行，甚至出现 “API First” 的设计思想。
RESTful API 是目前比较成熟的一套 web 应用程序的 API 设计理论，用于 web 前后端的数据交互。
RESTful API 路径
RESTful API 的路径又称 “终点”（endpoint），表示 API 的具体网址。
在 RESTful 架构中，每个网址代表一种资源（resource），比如：有一个 API 提供动物园（zoo）的信息，还包括各种动物和雇员的信息，则它的路径应该设计成下面这样：
https://api.example.com/v1/zoos
https://api.example.com/v1/animals
https://api.example.com/v1/employees
RESTful API HTTP 动词
在 RESTful API 设计理论中，对于资源的操作，由 HTTP 动词表示。
常用的 HTTP 动词有下面五个（括号里是对应的数据库 SQL 命令）。
- GET（SELECT）：从服务器取出资源（一项或多项）。
- POST（CREATE）：在服务器新建一个资源。
- PUT（UPDATE）：在服务器更新资源（客户端提供改变后的完整资源）。
- PATCH（UPDATE）：在服务器更新资源（客户端提供改变的属性）。
- DELETE（DELETE）：从服务器删除资源。
还有两个不常用的HTTP动词。
- HEAD：获取资源的元数据。
- OPTIONS：获取信息，关于资源的哪些属性是客户端可以改变的。
比如
- GET /zoos：列出所有动物园
- POST /zoos：新建一个动物园
- GET /zoos/ID：获取某个指定动物园的信息
- PUT /zoos/ID：更新某个指定动物园的信息（提供该动物园的全部信息）
- PATCH /zoos/ID：更新某个指定动物园的信息（提供该动物园的部分信息）
- DELETE /zoos/ID：删除某个动物园
- GET /zoos/ID/animals：列出某个指定动物园的所有动物
- DELETE /zoos/ID/animals/ID：删除某个指定动物园的指定动物
下面是一些例子
RESTful 即 Representational State Transfer 的缩写。直接翻译的意思是 “表现层状态转化”，是一种互联网应用程序的API设计理念：URL 定位资源，用 HTTP 方法描述操作，例如：
- 获取文章 /blog/getXxx Get blog/Xxx
- 添加文章 /blog/addXxx POST blog/Xxx
- 修改文章 /blog/updateXxx PUT blog/Xxx
- 删除文章 /blog/delXxxx DELETE blog/Xxx
