Restful API 和RPC API

作者: 黄靠谱 | 来源:发表于2019-05-04 18:03 被阅读256次

    总结一下

    • 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

    1. REST的主体是资源,而RPC更侧重于动作。

    2. REST更偏向外部调用,RPC更偏向内部调用。在国内,一般更偏向于RPC,比如阿里出的dubbo;在国外,更倡导REST,比如spring cloud,是个纯REST的项目,不支持RPC。(当然,近几年REST在国内也开始火起来了)

    3. REST其实是个效率很低的东西,特别是需要联合查询的时候;并且有些东西,也不好抽象成资源,比如用户登录、用户退出

    4. RPC只需要关心业务场景,但是如果业务理解不够,你可能不会理解这些API是做什么用的(优秀的RESTful API的设计,就算不懂业务,只要会一些英文,应该通过URL就能猜到每个API是做什么的)。

    5. 前端可能更喜欢REST,而后端估计更倾向于RPC。

    restful api细节

    还是看阮一峰大佬的博客吧,更详细,摘录几个印象比较深的点

    1. 必须要摒弃RPC的做法啊,比如新增用户
      标准写法: POST /users
      如果你写成 POST /users/add,那么就会有人写成: POST /users/insert ,POST /users/create,所以宾语必须是名词,而且最好是统一用复数

    2. 避免多级 URL
      GET /authors/12?categories=2

    3. response 必须是json的

    4. 返回正确的code

    参考

    阮一峰大佬的博客
    http://www.ruanyifeng.com/blog/2018/10/restful-api-best-practices.html

    讲区别的
    http://www.360doc.com/content/18/0730/00/99071_774291878.shtml

    相关文章

      网友评论

        本文标题:Restful API 和RPC API

        本文链接:https://www.haomeiwen.com/subject/anhfoqtx.html