多个端点以公开同一资源的不同视图答案

【问题标题】：Multiple endpoints to expose different views of the same resource多个端点以公开同一资源的不同视图
【发布时间】：2016-03-14 04:55:52
【问题描述】：

我正在努力寻找这个问题的答案（也许是因为我没有正确地问这个问题）......

我正在构建 API 以公开我正在创建的基本社交网络服务的资源。我的理解是，API 中的 URL 结构本质上是一个层次结构，类似于目录的结构。我认为这意味着我可以有多个端点来访问相同的资源或资源链接集合。例如：

我有一个端点

www.domain.api.org/users/{:uid}/posts

这将返回用户发送的所有帖子或用户被标记的帖子。看起来不错，但如果我有一个端点，例如：

www.domain.api.org/posts

当使用 http GET 时将返回所有公开帖子（即所有用户的帖子加上他的朋友和公开帖子）。

不同之处在于第一个 URL 指向用户拥有的资源，而第二个指向公共资源（其中当然包括用户的帖子）这些可以吗，还是我做错了/不太明智？

重申一下，我可以有多个端点指向同一资源的不同上下文/视图吗？

【问题讨论】：

标签： api rest url resources endpoint

【解决方案1】：

基本上应该避免相同资源的多个端点。但是在这种特殊情况下，它确实有意义。

您可以做的是将可选查询参数userId 引入以下端点：

www.domain.api.org/posts/?userId=<userId>

如果这替代了您提到的第一个端点，那就是要走的路。

【讨论】：

谢谢。不错的答案。它让我彻底重新思考了我的 url 设计方法。特别是，在任何 url 中都有 users/:uid 根本没有意义，因为只有登录和经过身份验证的用户才能查看该用户的资源，所以我只保留登录的用户 id成功登录后创建的访问令牌 (jwt)。
我认为对于像我这样的其他人来说，这值得指出，因为它仍然需要掌握良好的 url 端点设计。
为什么应该避免？有任何研究、资源、标准……支持这一说法吗？如果不遵循这个“应该”会发生什么？而且，基于项目特定的架构，它甚至可能是应该使用多个端点。应该的意见纯粹是主观的，除非在某些情况下得到推理的支持。

【解决方案2】：

我想在@Opal 的答案之上添加。

这些没问题还是我做错了/不太明智？

理想情况下，就像 Opal 提到的那样，您应该在 url 中使用 queryParams。对于我构建的许多应用程序，我事先不知道从 api 返回的 uid，因此选择一个项目并将其作为查询参数传递到我的 url 中是有意义的。但它还有一个额外的好处，就是将您的密钥放在您的 url 中，允许您将其添加为书签，将 url 传递给其他用户，他们将自动看到您希望他们看到的相同数据。

迭代：您当前的实现是否错误？ 不，但理想情况下你会use a combination of both route parameters are query parameters to achieve this

【讨论】：

【解决方案3】：

要创建端点，您必须确保立即获得这些信息：

端点名称
状态：激活与否（必需）- 端点是激活还是禁用
服务配置文件（必需）- 分配给端点的服务配置文件的 ID。
关税配置文件（必需）- 分配给端点的关税配置文件的 ID。

您可以添加其他可选信息，并确保您的端点的结构。希望对您有所帮助。

【讨论】：