这是一个创建于 3070 天前的主题，其中的信息可能已经有所发展或是发生改变。
如果设计 RESTful 架构设计风格, 我觉得还是描述不清楚项目中的所有的场景. 比如说校验验证码的验证, 这个场景按照 RESTful 的风格设计应当如何设计呢?
第 1 条附言 · 2016-06-29 10:53:13 +08:00
感谢大家的积极回复, 看完了之后感想如下:
1. 关键还是看抽象资源能力. 抽象能力绝佳的话, 可以描述清楚.
2. 如果感觉描述不清楚, 请参考上面一条.
-------------------------------------------------------------------------------
ps
个人觉得:
过分的抽象, 影响对于系统的理解.
因此, 还是适度吧~
1. 关键还是看抽象资源能力. 抽象能力绝佳的话, 可以描述清楚.
2. 如果感觉描述不清楚, 请参考上面一条.
-------------------------------------------------------------------------------
ps
个人觉得:
过分的抽象, 影响对于系统的理解.
因此, 还是适度吧~
 |
1
eecjimmy OP |
 |
2
imzshh 2016-06-27 10:46:48 +08:00  1
之前做过验证码服务的接口设计，不确定是不是正确的做法，你自己看吧。
有 3 个主要接口： 1. POST /captchas 2. GET /captchas/:key 3. DELETE /captchas/:key?answer=<answer> 在需要展示验证码的时候，先由服务器或者前端调用接口 1 创建验证码，接口返回 key ；拿到 key 后调用接口 2 ，这个接口根据 Accept 头返回图片或者音频。 校验验证码的时候，调用接口 3 ， answer 是用户输入的验证码上的文字。 |
|
3
eecjimmy OP 谢谢 @imzshh 。
其实我更多的是有一种疑问，就是 restful 风格真的能够处理掉类似的场景吗? 还是很多的时候, 都是看程序猿自身的? 可能还有更多类似的场景, 比如批量导入 excel 的功能等等。 |
 |
4
abelyao 2016-06-27 11:06:53 +08:00
|
 |
5
learnshare 2016-06-27 11:08:05 +08:00
RESTful 讲究的是资源化，有些东西是过程化的，不是资源化
|
|
6
eecjimmy OP @abelyao 那比如说 url 设计的话，这种一般如何设计呢？ post http://api.xxx.com/users ？最近总在想这些乱七八糟的问题。。
|
|
7
eecjimmy OP @learnshare 嗯， 抽象资源是关键，但是很多时候抽象难度真的好大。
|
 |
8
zdkmygod 2016-06-27 11:09:39 +08:00
后端数据库不也是 curd ，我觉得应该把 restful 当成数据库接口进行交互。
|
|
9
abelyao 2016-06-27 11:10:15 +08:00
@eecjimmy 不用想得太多啊，以后觉得有更合适的方案再修改就行了，没有什么设计是一次到位的，互联网也都修订了多少次了，如果一开始就全部考虑到位，今天也不会有人提出 RESTful 的概念
|
|
10
eecjimmy OP @zdkmygod 前端上面的一个请求， 反馈到后端上面，可能是很复杂的，也可能是很多个表的，或者是没有数据表的，这话总场景实际还是很多的。
|
 |
12
laoyuan 2016-06-27 11:57:47 +08:00
像淘宝搜索页的那些筛选参数， url 怎么处理？
|
|
13
imzshh 2016-06-27 12:07:56 +08:00
@learnshare 过程化的东西必然伴随着状态的变化，正是适合 REST 的部分。
|
 |
14
srlp 2016-06-27 13:14:15 +08:00 1
@eecjimmy post http://api.xxx.com/users 很对。
|
 |
15
msg7086 2016-06-27 13:41:18 +08:00
restful 并不是绝对。过度要求范式并不见得就好。
|
 |
18
otakustay 2016-06-27 16:16:44 +08:00 1
能，前提是你的系统架构和设计是 rest 的，而不是先采用了以动作为第一维度的设计，然后再套 rest 的 verb
|
 |
19
jswh 2016-06-27 16:49:46 +08:00 1
restful 风格是面向资源的，每个地址描述一个唯一的资源，然后靠返回的其他资源地址来形成资源之间的关系，并用 http 的 verb 来描述对资源的操作。所以应该是先把数据抽象成某种资源，然后定义操作，再形成 restful 的地址。个人理解
> REST 是 关于 信息 管理 的， 而 不一定 是 通过 URL 来 调用 任意 的 行为。 当人 们 开始 挠头 思考 4 个 动词 是否 足够 完成 他们 想做 的 事情 时， 他们 想 的 也许 不是 信息， 而是 在想 调用 的 行为。 > —架构之美 |
 |
20
lightening 2016-06-27 16:56:14 +08:00 1
不能，所以可以有例外。但是绝大多数情况可以。
注意 resource 不一定要对应 model ，可以是抽象的。楼主的场景，校验验证码的验证， verification 是一个 resource ，验证这个动作就是 create 一个 verification 。 verification 本身是一个抽象名词。 比如把 users 放进 group ，就是 create 了一个 “ membership ”。 如果仔细想想，很多过程可以看做对于一个抽象资源的增删查改操作。 可以参考 DHH 对于 Resources 的演讲： |
|
21
eecjimmy OP @lightening
@jswh @otakustay -------------------------- 谢谢回复, 但是如果只是为了资源而“抽象”的话，会不会导致加大了系统的理解的难度了呢，反而没有直接接口来的更明了一些？ youtube 挂了, 晚上回去挂 VPN 再学习下。 这好像是有一个悖论似的，过分的抽象，加大了理解的难度，如果不用 RESTful 的风格，又紧耦合了各个接口之间的关系。 |
|
22
lightening 2016-06-27 17:34:42 +08:00 1
@eecjimmy 一般来说对于大一点项目， RESTful 会降低复杂程度。自己设计的话，搞得不好会难以维护。不过用不用 REST 本来就是你自己的决定。
|
Select Language