REST API设计 - 通过REST获取具有不同参数但相同url模式的资源
棋牌 发布于 2023-02-12 19:41我有一个与REST网址设计相关的问题.我在这里找到了一些相关的帖子:同一资源的不同RESTful表示,这里:RESTful url来获取不同字段的GET资源,但响应并不十分清楚最佳实践是什么以及为什么.这是一个例子.
我有用于表示"用户"资源的REST URL.我可以使用id或电子邮件地址获取用户,但两者的URL表示形式保持不变.通过大量的博客和书籍,我看到人们已经以不同的方式做到了这一点.例如
在书中和stackoverflow上的某个地方阅读这个练习(我似乎无法再找到链接)
GET /users/id={id}
GET /users/email={email}
在很多博客上阅读这种做法
GET /users/{id}
GET /users/email/{email}
查询参数通常用于过滤网址所代表的资源的结果,但我也看到了这种做法
GET /users?id={id}
GET /users?email={email}
我的问题是,在所有这些实践中,对于使用api的开发人员来说哪一个最有意义？为什么？我相信在REST网址设计和命名约定方面没有任何规则,但我只是想知道应采取哪条路线来帮助开发人员更好地理解apis.
所有帮助赞赏!
-
从实用的角度来看,你有一组用户:
/users # this returns many
每个用户都有一个专用的资源位置:
/users/{id} # this returns one您还可以通过多种方式搜索用户:
/users?email={email} /users?name=*bob*由于这些都是/ users的查询参数,因此它们都应该返回列表..即使它是1的列表.
我写了一篇关于实用RESTful API设计的博客文章,其中讨论了这一点,其中包括:http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api
2023-02-12 19:43 回答
软装之家888 -
根据我的经验,这
GET /users/{id} GET /users/email/{email}是最常见的方法.如果用户不存在提供的id或者,我也希望这些方法返回404 Not Foundemail.我也不会感到惊讶GET /users/id/{id}(尽管在我看来,这是多余的).对其他方法的评论
GET /users/id={id} GET /users/email={email}我不认为我已经看过这个,如果我确实看到了它,那将是非常令人困惑的.这几乎就像它试图用路径参数模仿查询参数.
GET /users?id={id} GET /users?email={email}当你提到使用查询参数进行过滤时,我认为你在头上钉了一针.
它会永远是有意义的调用与该资源都在
id和email(例如GET /users?id={id}&email={email})？如果没有,我不会使用这样的单一资源方法.我希望这种方法可以检索具有可选查询参数的用户列表进行过滤,但我不希望这样
id,email或者任何唯一标识符都在参数中.例如:GET /users?status=BANNED可能会返回禁止用户列表.从相关问题中查看此答案.
2023-02-12 19:43 回答
少女24梦_276
京公网安备 11010802041100号