RESTful 的 verb 真的能把实际项目中碰到的所有场景都能描述清晰吗?

[eecjimmy]

如果设计 RESTful 架构设计风格, 我觉得还是描述不清楚项目中的所有的场景. 比如说校验验证码的验证, 这个场景按照 RESTful 的风格设计应当如何设计呢?

感谢大家的积极回复, 看完了之后感想如下:
1. 关键还是看抽象资源能力. 抽象能力绝佳的话, 可以描述清楚.
2. 如果感觉描述不清楚, 请参考上面一条.
-------------------------------------------------------------------------------
ps
个人觉得:
过分的抽象, 影响对于系统的理解.
因此, 还是适度吧~

[eecjimmy]

SF 镜像地址: https://segmentfault.com/q/1010000005807296

[imzshh]

之前做过验证码服务的接口设计，不确定是不是正确的做法，你自己看吧。

有 3 个主要接口：
1. POST /captchas
2. GET /captchas/:key
3. DELETE /captchas/:key?answer=<answer>

在需要展示验证码的时候，先由服务器或者前端调用接口 1 创建验证码，接口返回 key ；拿到 key 后调用接口 2 ，这个接口根据 Accept 头返回图片或者音频。
校验验证码的时候，调用接口 3 ， answer 是用户输入的验证码上的文字。

[eecjimmy]

谢谢 @imzshh 。
其实我更多的是有一种疑问，就是 restful 风格真的能够处理掉类似的场景吗? 还是很多的时候, 都是看程序猿自身的?
可能还有更多类似的场景, 比如批量导入 excel 的功能等等。

[abelyao]

@eecjimmy
当然也是看程序猿自身咯，水平太次的话，传统模式也能写得乱七八糟。
导入 Excel 不就相当于把文件上传给后端处理嘛？上传文件总会吧

[learnshare]

RESTful 讲究的是资源化，有些东西是过程化的，不是资源化

[eecjimmy]

@abelyao 那比如说 url 设计的话，这种一般如何设计呢？ post http://api.xxx.com/users ？最近总在想这些乱七八糟的问题。。

[eecjimmy]

@learnshare 嗯， 抽象资源是关键，但是很多时候抽象难度真的好大。

[zdkmygod]

后端数据库不也是 curd ，我觉得应该把 restful 当成数据库接口进行交互。

[abelyao]

@eecjimmy 不用想得太多啊，以后觉得有更合适的方案再修改就行了，没有什么设计是一次到位的，互联网也都修订了多少次了，如果一开始就全部考虑到位，今天也不会有人提出 RESTful 的概念

[eecjimmy]

@zdkmygod 前端上面的一个请求， 反馈到后端上面，可能是很复杂的，也可能是很多个表的，或者是没有数据表的，这话总场景实际还是很多的。

[eecjimmy]

@abelyao 做着做着就发现， url 就开始丑陋不堪。。。

[laoyuan]

像淘宝搜索页的那些筛选参数， url 怎么处理？

[imzshh]

@learnshare 过程化的东西必然伴随着状态的变化，正是适合 REST 的部分。

[srlp]

@eecjimmy post http://api.xxx.com/users 很对。

[msg7086]

restful 并不是绝对。过度要求范式并不见得就好。

[eecjimmy]

@srlp 但是场景是导入, 如果是创建用户, 批量创建用户, 也用这个?

[eecjimmy]

@msg7086 嗯嗯, 谢谢, 但是实际我说的这些场景其实都是很常见的场景.

[otakustay]

能，前提是你的系统架构和设计是 rest 的，而不是先采用了以动作为第一维度的设计，然后再套 rest 的 verb

[jswh]

restful 风格是面向资源的，每个地址描述一个唯一的资源，然后靠返回的其他资源地址来形成资源之间的关系，并用 http 的 verb 来描述对资源的操作。所以应该是先把数据抽象成某种资源，然后定义操作，再形成 restful 的地址。个人理解

> REST 是 关于 信息 管理 的， 而 不一定 是 通过 URL 来 调用 任意 的 行为。 当人 们 开始 挠头 思考 4 个 动词 是否 足够 完成 他们 想做 的 事情 时， 他们 想 的 也许 不是 信息， 而是 在想 调用 的 行为。
> —架构之美

[lightening]

不能，所以可以有例外。但是绝大多数情况可以。

注意 resource 不一定要对应 model ，可以是抽象的。楼主的场景，校验验证码的验证， verification 是一个 resource ，验证这个动作就是 create 一个 verification 。 verification 本身是一个抽象名词。

比如把 users 放进 group ，就是 create 了一个 “ membership ”。

如果仔细想想，很多过程可以看做对于一个抽象资源的增删查改操作。

可以参考 DHH 对于 Resources 的演讲：

[eecjimmy]

@lightening
@jswh
@otakustay
--------------------------
谢谢回复, 但是如果只是为了资源而“抽象”的话，会不会导致加大了系统的理解的难度了呢，反而没有直接接口来的更明了一些？ youtube 挂了, 晚上回去挂 VPN 再学习下。
这好像是有一个悖论似的，过分的抽象，加大了理解的难度，如果不用 RESTful 的风格，又紧耦合了各个接口之间的关系。

[lightening]

@eecjimmy 一般来说对于大一点项目， RESTful 会降低复杂程度。自己设计的话，搞得不好会难以维护。不过用不用 REST 本来就是你自己的决定。

[msg7086]

@eecjimmy 所以我上面就说了，过度要求范式不见得就好。
restful 本身就是一种风格，并不需要为了 restful 而 restful 。