这是一个创建于 2960 天前的主题，其中的信息可能已经有所发展或是发生改变。
获取某个用户发布的文章：
是
api/v1/user/{userId}/posts
还是
api/v1/user/posts/{userId}
还是
api/v1/user/posts?userId={userId}
呢？
 |
1
yangyifan 2016-11-18 11:40:48 +08:00 via iPhone
第一种
|
 |
2
wayn3h0 2016-11-18 11:40:59 +08:00
RESTful:
GET api/v1/users/{uid}/posts |
 |
3
mhycy 2016-11-18 11:41:29 +08:00
从客户端合成 URI 的角度来看
2>3>1 从扩展能力看 2>1>3 1 、 2 都能添加 get 形式后缀， 3 的 GET 形式后缀会与必要的 userid 冲突 从 URI 路由效率来看 3>2>1 综上所述，选择 2 |
 |
4
murmur 2016-11-18 11:44:02 +08:00
我选择第三个，这个链接我闭着眼睛都能扩展为
api/v1/user/posts?userId={userId}&pageSize=20&page=5&search=java 用 restful 的你们继续想吧 restful 如果能做到的， query param+nginx rewrite 就可以轻松做到 反之可未必 |
 |
5
huijiewei 2016-11-18 11:48:19 +08:00
避免层级过深的 URI
/在 url 中表达层级，用于按实体关联关系进行对象导航，一般根据 id 导航。 过深的导航容易导致 url 膨胀，不易维护，如 GET /zoos/1/areas/3/animals/4 ，尽量使用查询参数代替路径中的实体导航，如 GET /animals?zoo=1&area=3 |
 |
6
elvba 2016-11-18 11:55:35 +08:00  2
我选择 api/v1/users/{userId}/posts
以及说用 restful 就不是用 ?fidle=value&search=value 的意思，查询参数可以对获取的资源再进行过滤 api/v1/user/posts?userId={userId}&pageSize=20&page=5&search=java 然而这也是 resful 风格…… 获取所有用户的文章，再用查询参数进行过滤 参考： http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api |
 |
7
lrh3321 2016-11-18 13:24:25 +08:00
我选 第一种
截 api/v1/user/{userId} 出来，很容易就找到了发文章的用户 |
 |
8
jerray 2016-11-18 13:50:44 +08:00
支持 #6 选 1
|
 |
9
wupher 2016-11-18 14:00:01 +08:00
支持第一种，但是如果是长期项目，不赞成版本号放到 URL 上。
|
 |
10
mornlight 2016-11-18 14:00:37 +08:00
我倾向第一种， post 和 user 有明显的归属关系
|
 |
11
baiyi 2016-11-18 16:43:59 +08:00
第一种 支持 #6 的看法
|
 |
12
keepcleargas 2016-11-18 16:49:27 +08:00
第一种. 实际使用中 也是.
|
 |
13
wesley 2016-11-18 16:55:24 +08:00
用 api/v1/posts?userId={userId}
这样只提供一个接口 否则的话，返回某人的 post 要做一个接口， 返回某喵的 post 又要一个接口，返回某汪的 post 又又要一个接口 |
|
14
mhycy 2016-11-18 17:00:03 +08:00
|
 |
15
learnshare 2016-11-18 18:12:48 +08:00
RESTful
user/{userId}/post 不是 posts |
|
17
wupher 2016-11-21 08:46:15 +08:00
|
 |
18
Jakesoft OP 综合楼上各位的观点，发现我提到的三点几乎每一个都有不少人支持或者在使用，当然大家都有自己的理解，我有时候也很困惑该使用哪种 api 风格，是否有必要严格遵守 REST 呢？我也发散一下我的浅见吧，如有不妥请多读包涵
对于一个获取订单的 api ，我们自然联想到使用 GET 请求，但是这个获取起始后台做了很多事情，比如： 1.通知卖家有人查看了你的商品 2.在`我的历史查看`做记录 3.在`哪些人最近查看了该商品`做记录 ... 这似乎就是一个 “我把我的信息给你，你做一下这些（上述）操作，完了把我要的东西给我”的请求 那这还是一个纯粹的 GET 请求吗？ REST 似乎强调 header 以及 http code 的重要性，但实际上： 1.header 不能随意添加， client 可能不识别不安全的 header,并且我们不能直观的从 url 上得到确切的 api 信息，往往还需要看 header 。 2.http code 难以记忆，并且业务复杂的系统还是需要业务 code 来处理，所以除了 200 ， 400 ， 500 这些常用的 code 之外，其余的似乎并不能更好的让你开发 api |
Select Language