作者ripple0129 (perry tsai)
看板Soft_Job
标题Re: [请益] 所以,到底什麽是RESTful API?
时间Mon Mar 11 21:26:25 2019
很多人以为
/users?id=1
改成
/users/1
就是Restful了
Restful是个风格
不过不是改个route, controller样貌就叫Restful
以前自己在看的时候
比较难理解的个人觉得有两个地方
第一就是资源点观念
先来讲讲上面的观念差异
/users?id=1
用资源点的观念来看
就是资源点在/users
我要从users中query出id是1的user
所以说不是有parameter的就不是Restful
一样能用资源点的观念解释
/users/1
这个1代表什麽自行定义吧
如果1代表的是group的话呢
users/1就是users被定义於group 1的资源点
可能也是多数也可以再用parameter query它
就像users/1?age<10
资源点就是这样的概念
所以不是单纯route的样貌就决定是不是Restful
当然多数我们在设计时还是习惯会多个提醒
弄成这样/users/group/1
照这样讲好像怎样解释都行的通？
当然不是这样子
资源点要是名词
当有route被设计成
/get-user-password?account=abc
这样的设计就偏离Restful了
因为带有动词的意味
第二个比较难理解就是无状态
无状态的定义就是你每次的request
都跟你之前的request无关
说的这麽复杂直接讲白点就是
不要用session啦
过往设计可能会有第一次request
存点资料在session
下次request可能拿来用
不过这就背离Restful啦
而无状态的好处是很明显的
因为没有状态server只是取得资源点的地方
所以可以轻松的达成
多台Server提供服务
你每次的request连接到哪一台都没差
要判断你的设计是不是无状态的
单纯就考量这一点即可
能否Server多开後
同一使用者的Request
就算轮着一台一台戳也不会有问题
其他的观念
个人觉得都算容易理解也不用赘述了
当然由於Restful没明确指示做法
这是我个人解读
觉得有误也请指正了
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 115.82.1.106
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1552310788.A.1B9.html
1F：推 shter: 老实说开头两例我还满不喜欢 /users/1 这种风格的03/11 21:45
2F：→ bibo9901: 奇怪. 难道有人觉得Get(User, 1)是很直觉的写法吗?03/11 21:45
3F：→ shter: 因为这局限了查询的层次，我要找就一定要 /users/1 底下找03/11 21:46
4F：→ bibo9901: 任何人写程式都是觉得 User.get(1) 比较直觉吧? 为什麽03/11 21:46
5F：→ bibo9901: 变HTTP时就会自动想要"RESTful"?03/11 21:46
6F：→ bibo9901: 说白了就是HTTP协定本来就不是为了API设计，只是方便易03/11 21:47
7F：→ bibo9901: 用所以流行而已. 又"刚好" HTTP methods 对应了最常见的03/11 21:48
8F：→ bibo9901: 几种操作, 仅此而已. 没必要把URI硬套"资源导向设计"03/11 21:49
9F：推 shter: 不知何时开始，Web变的很重视 router 这种东西03/11 21:51
放心啦
以後剩下/graphQL而已XD
※ 编辑: ripple0129 (115.82.1.106), 03/11/2019 21:53:30
10F：→ shter: 写 users/1 变的像写地址一样，县市/乡镇市区/路/段/号/楼03/11 21:52
11F：→ shter: 可是你还是要看 Doc 才能操作 API03/11 21:53
12F：→ shter: 不然你不知道每一层 / 底下代表的是什麽意思03/11 21:54
13F：→ shter: 这样跟传统 ?search 看 Doc 查变数名称没啥不同03/11 21:54
14F：→ bibo9901: 像你举的例子 /user/group/1, 到底是 "user之下的group"03/11 21:54
15F：→ bibo9901: 还是 "在group1里的user"? 1-1, 1-n, n-1, n-n 的关系跟03/11 21:55
16F：→ bibo9901: 本无法表达, 最後还不是要查doc. 既然都要查doc, 写成03/11 21:55
17F：→ bibo9901: /get_user_by_group/1 又有何防? 还更加清楚03/11 21:56
18F：→ shter: 总觉得可能跟物件导向习惯一路 .下去还是 -> 指过去一样吧03/11 21:56
19F：推 shter: graphQL 让我想到乾脆把整串JSON base64丢来丢去的日子 03/11 22:03
20F：→ bibo9901: graphQL有spec,SAOP,JSON-RPC,XML-RPC都是协定(有spec) 03/11 22:09
21F：→ bibo9901: REST没有spec, 就是风格建议而已, 为什麽? 因为定出来就 03/11 22:09
22F：→ bibo9901: 不够简单了. 03/11 22:10
23F：推 longlongint: 我比较喜欢 mov je 03/11 22:11
24F：→ alan3100: ..举例错误呀 是/groups/{groupId}/users 03/11 22:40
25F：→ CaptainTeemo: /get_user_by_group/1 是很糟糕的设计，而且使用 HA 03/12 05:51
26F：→ CaptainTeemo: TEOAS 可以减少频繁查 doc 03/12 05:51
27F：推 goodblessu: 如果把session存在另一台redis，这样算不算无状态 03/12 08:14
28F：→ SuM0m0: 头一次看过有人用命名风格定义RESTful 03/12 11:38
29F：推 csieflyman: 请问大家何时使用单数或复数? 例如 /users 是用复数03/12 12:24
30F：→ csieflyman: 但/users/1/friends 是否用单数比较合理 /user/1/fri03/12 12:24
31F：→ csieflyman: ends03/12 12:24
32F：推 csieflyman: 另一个问题是 batch api 就是允许一次 POST jsonArray03/12 12:32
33F：→ csieflyman: 多笔资料 要怎麽突显出来? 例如 /users/batch 或是 /03/12 12:32
34F：→ csieflyman: users 然後再多描述要传 jsonarray 此外如果习惯用03/12 12:32
35F：→ csieflyman: 复数 是否会有人以为可以 POST 多笔资料?03/12 12:32
36F：推 csieflyman: 最後一个问题 当有多个动作修改某个资源时 但却只有一03/12 12:39
37F：→ csieflyman: 个 PUT 可以表达时 是否只能在 URL 标示动词? 或是有03/12 12:39
38F：→ csieflyman: 更好的作法?03/12 12:39
39F：推 MangoTW: 先推这篇有比较提到 pattern 了03/12 13:27
40F：→ MangoTW: 楼上说的单复数问题 URL 是资源定址在 RESTful 正规化为03/12 13:29
41F：→ MangoTW: collections/element 的形式所以你是在 users 集合里新增 03/12 13:30
42F：→ MangoTW: users/1 则是集合中的某单一资源 是合语意的 03/12 13:31
43F：推 csieflyman: 我自己都是用复数 但有同事问我上面这几个问题 我不 03/12 13:37
44F：→ csieflyman: 知如何解释比较好 主要是 /users/1/friends 为何不是 03/12 13:37
45F：→ csieflyman: 单数? 毕竟只是针对 user 1 这1个人的朋友做操作 03/12 13:37
46F：推 csieflyman: 虽然大家对Restful 风格有一些共识了 但细节上还是会 03/12 13:40
47F：→ csieflyman: 有人有不同的想法 03/12 13:40
细节本来就没有严谨定义了
只是convention 大家都用复数
你要用单数也没人可以说错
但这个范例我个人觉得friends是复数啊
users/1的朋友们
users/1/friends/2这样才觉得是单数
※ 编辑: ripple0129 (115.82.1.106), 03/12/2019 13:51:34
48F：→ alan3100: 就只是你跟你同事脑袋转不过来而已 你可以google没s的少 03/12 13:50
49F：→ csieflyman: friends是复数没错 我指的是users是否应该是单数 user 03/12 13:57
50F：→ csieflyman: 我後来是跟他说 我看 Web API: the good parts 这本 03/12 14:01
51F：→ csieflyman: 书 大多数人用复数 但我觉得用多数法则的理由压人是否 03/12 14:01
52F：→ csieflyman: 会让人不服气 03/12 14:01
53F：→ brucetu: flyman大 因为/users/传回多笔 /users/1 传回一个user 03/12 15:35
54F：→ brucetu: /users/1/something 就是根据这个user再往下取资料 03/12 15:35
55F：→ brucetu: 如果这个something是一个集合 就用复数 03/12 15:36
56F：→ brucetu: 因为这样比较符合语意不单纯是多数人使用的问题 03/12 15:36
57F：→ brucetu: 就好像一个json描述的资源 , 集合通常用复数命名 03/12 15:37
58F：推 bibo9901: 争这个就好像回字有四种写法一样 03/12 16:07
59F：→ ku399999: 一般用users/1 我觉得一来表示对这操作id是required,二 03/14 09:40
60F：→ ku399999: 来明确表示整个系统只会有一个id=1的item 03/14 09:40
61F：→ infixman: user们的1号的friend们的1号 03/19 07:25
62F：→ infixman: 既然是“们”，加个s不是理所当然? 03/19 07:26