总结一下
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=2
response 必须是json的
返回正确的code
参考