php rpc restapi6,Restful API 和RPC API

总结一下

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

参考