idea from https://apihandyman.io/do-you-really-know-why-you-prefer-rest-over-rpc/

什么是 API 的 RPC 风格? 而什么又是 REST 风格?

通常后来者年轻人都会趋向于 REST 风格吧, 基于 JSON 响应内容格式, 各种大行其道的 web framework. 究竟在我们想要选择某个设计的时候是否考虑我们更加趋向于面向资源的 REST 风还是面向操作的 RPC 风呢? RPC 就很 low 而 REST 就看上去高上大?

这里先来看看 RPC 和 REST 他们看上去到底什么样子.

在对比之前我们先看看他们长什么样子吧.

HTTP 请求

对于 RPC 和 REST 来说, 他们都是使用了 HTTP 协议来表达实现一个 http 的请求, 一个所谓的 http 请求它就包括了动作和资源.

verb
resource

对于动作来说,

get 获取资源操作幂等安全可缓存
post 创建资源或者出发数据处理不幂等不安全可部分缓存
put 完全创建一个对象或者替换幂等不安全不可缓存
patch 部分更新资源不幂等不安全部分缓存
delete 删除一个资源幂等不安全不可缓存

RPC 操作请求风格

对于 RPC 来讲,它通常代表remote procedure call, 这里我们把它理解成为 WYGOPIAO, 也就是 what you get or post is an operation. 通过这个 RPC 类型,你通过 http 协议暴露出自己的动作以及数据封装. 据我所知, 通常也没有什么规则可循, 但是大致是这样的:

endpoint 通常都是包括动作名称的
通常只是使用 get 或者 post 来通信

GET /someoperation?data=anId

POST /anotheroperation
{
  "data":"anId"; 
  "anotherdata":"another value"
}

那么通常又是怎么选择get 或者 post 呢?

get 通常也就是只是获取而不修改东西
不考虑什么http 协议, 只是通过少许参数来获取而非大量的参数
基本上都用 post

REST 风格

这里不谈什么是 REST, 而就单单说说如何通过 REST 描述表达及操作 http 协议.

endpoint 通常会包含要操作的资源
通常会使用 CRUD 来描述对于资源的操作

GET /someresources/anId

PUT /someresources/anId
{"anotherdata":"another value"}

比较 RPC 和 REST

优雅
设计
API 定义语言
可预测和语义性
超媒体
可缓存
可用

REST 挺好?

其实 REST 胜在哪里? 我想也就是可预测性和语义性了. 而面向资源和面向操作, 哪个更好? 仁者见仁.