总结一下
- RESTful 是目前最流行的 API 设计规范，用于 Web 数据接口的设计。（感觉比较适合大型项目、多团队合作项目）
- RPC的核心思想是把本地的方法映射到API，比如我本地有一个方法是getUser()
RESTful的可读性更好，即使完全不了解业务，看到API也知道这个接口是干嘛的，但是有时候不好抽象，比如login操作，你用Restful如何抽象？
Restful规范最大的好处：命名统一，避免相同的功能因为命名风格不同，而创建了一大堆冗余的接口。既浪费了编程资源（相同的功能写了多个接口），又不好维护（修改一个功能，要修改多个命名不同的接口）
RPC规范的话，当然是简单暴力，后端程序员更喜欢，写给自己小伙伴的接口规范，但是在大型项目、多team合作项目、前后端分离项目时，可读性很差。有时候一个功能相同接口，会出现好几个。因为可能项目移交给别的team做，新team没空研究之前的代码，直接写一个新的接口完成同一个业务功能。
比如
- /getUser?id=，
- /getUserById?id=
- /getUserByPrimary?id=
但是有了restful规范的话，就可以大大降低这种事情的概率，因为都是 GET /users/{id}
REST VS RPC
REST的主体是资源，而RPC更侧重于动作。
REST更偏向外部调用，RPC更偏向内部调用。在国内，一般更偏向于RPC，比如阿里出的dubbo；在国外，更倡导REST，比如spring cloud，是个纯REST的项目，不支持RPC。（当然，近几年REST在国内也开始火起来了）
REST其实是个效率很低的东西，特别是需要联合查询的时候；并且有些东西，也不好抽象成资源，比如用户登录、用户退出
RPC只需要关心业务场景，但是如果业务理解不够，你可能不会理解这些API是做什么用的（优秀的RESTful API的设计，就算不懂业务，只要会一些英文，应该通过URL就能猜到每个API是做什么的）。
前端可能更喜欢REST，而后端估计更倾向于RPC。
restful api细节
还是看阮一峰大佬的博客吧，更详细，摘录几个印象比较深的点
必须要摒弃RPC的做法啊，比如新增用户
标准写法： POST /users
如果你写成 POST /users/add，那么就会有人写成: POST /users/insert ,POST /users/create，所以宾语必须是名词，而且最好是统一用复数避免多级 URL
GET /authors/12?categories=2response 必须是json的
返回正确的code
参考
阮一峰大佬的博客
http://www.ruanyifeng.com/blog/2018/10/restful-api-best-practices.html
讲区别的
http://www.360doc.com/content/18/0730/00/99071_774291878.shtml
