问题标签 [url-design]

我从一个列表视图开始，其中列表视图中的每个项目都是一个项目，每个项目都有一个唯一的 _id，仅显示部分信息，单击它们将路由到另一个页面并显示所有信息。现在，我单击一个项目，路由到唯一 ID 和一个全新的组件，然后，在新组件中，我获取该唯一 ID，在我的 MongoDB 数据库中搜索该唯一 ID，然后显示找到的项目。

如果没有，有什么更好的方法？我试图模拟 youtube 的 URL 设计（至少在我看来是这样），在主页上，它们显示许多视频，然后在点击时，它们路由到 /watch + 特定 id，然后显示视频。

在我的应用程序中，我重定向了一个 HTTP 请求并传递了一个参数。例子：

使用 a 更好;还是应该使用?ie 我应该做http://localhost:9000/home;signup=error还是http://localhost:9000/home?signup=error？

以上两者在语义上是否相互不同？

我们使用的是 Hybris 平台，我们的产品 URL 如下所示。

我是 Hybris 平台的新手，但我了解 URL 结构，我认为这里出了点问题。我检查了其他 Hybris 网站，其他 Hybris 网站的 URL 又短又干净。有什么建议吗？

我想设计一个 RESTful URL 来选择具有特定类别的设计师。

这是我的域关系：

我想到了两种方法：

• 首先，仅使用 URI 路径：/categories/{id}/products/designers
• 其次，使用查询字符串：/designers/?categoryId={id}

我想知道什么更好。

我需要使用 SEO 友好和分层 URL 在 Laravel 中创建一个站点（电子商店）。

一些例子是：

• www.example.com/cat1/cat11（指向一个类别产品列表）
• www.example.com/cat1/cat11/cat111（指向一个类别产品列表）
• www.example.com/cat1/cat11/cat111/product-title（指向产品详细信息页面）
• www.example.com/contact-us（指向一个页面）

我可以解析上述 URL 并找到所需的 slug，但我不确定哪个控制器将负责每条路由。

可能的想法：

1) 为每个 URL 类型添加前缀，以便了解控制器，例如

• www.example.com/categories/cat1/cat11/cat111> 类别控制器
• www.example.com/products/cat1/cat11/cat111/product-title> 产品控制器
• www.example.com/page/contact-us> 页面控制器

2) 预先生成所有站点的 URL 并将其存储在一个表中。该表可以包含两列：URL (cat1/cat11/cat111) 和 model:id (category:8) 全局控制器将解析 URL 并使用该表可以加载所需的模型和 id。

还有什么想法吗？

我正在构建具有发票的 REST 端点。我需要在 3 个描述级别中构建所有发票的列表（详细信息是默认的，仅汇总，一个包含客户信息）。

我还需要为单个发票构建端点，其中将包含更多信息。

我刚在想

但我看到其他人可能实现了两个不同的

我已经从阅读中知道，所有这些都可以算作 REST，如果有什么我需要用链接制作一个，那么它就是 HATEOAS，我没有真正需要它的理由。

我的问题更多是从实际的角度来看，例如哪个更容易实施、更安全、更常见。

我可能会在服务器上使用 python 和 Flask，如果这很重要，我编写的一个客户端将是 JQuery。

是否有人知道可以帮助将有关 URL 设计的讨论从意见和情感转移到研究、文档和事实的文档、RFC、指南或研究？

假设我们正在构建一个传统的非 SPA 基于 HTML 的银行应用程序，人们可以在其中选择帐户。当前选择的帐户是 UI 状态。这个选定的帐户可以（至少）以以下两种方式“存储”：

1. 在 URL 中喜欢https://mybank.com/balance?accountID=23423498或https://mybank.com/accounts/23423498/balance
2. 在其他地方，例如在 cookie 中或在会话状态中，以便https://mybank.com/accounts/balance显示当前选择的帐户的余额，无论它可能是什么。

#1 使深层链接和多个选项卡成为可能，而 #2 产生更干净/更简单的 URL，特别是如果有多个这样的 UI 状态“维度”并使实现更简单。实际上，我们在任何给定时间都有 1-3 个这样的 UI 状态维度。

我对此事的个人意见并不重要，因为我不是在寻找意见。我的问题是，任何一方都无法通过指向权威文档、研究或设计指南的链接来支持我们的“观点”，这些链接阐明了何时使用什么。

注意：我不是在寻找有关 URL、cookie 或会话如何工作、它们的存储位置等的技术细节，而是关于何时将这些信息放入 URL 以及何时不放入的建议。

我有一个系统，登录的用户可以对帖子投票喜欢或不喜欢。如果他们试图点赞一个已经被点赞的帖子，他们将删除该帖子的投票。同样适用于不喜欢。作为一个 REST 新手，我正在尝试为此提出一个 url 方案，这令人困惑

目前，我的网址看起来像这样

一个端点正在做所有事情，登录用户才是真正可以投票的用户

在阅读了有关 stackoverflow 的其他一些答案后，似乎还有其他可能性

我已经看到其他答案，其中 userId 也包含在 url 中，因为它说 REST API 设计不应该反映有状态

这些 url 的问题是任何人都可以更新任何 userId 的投票，除非涉及一些后端检查

我的问题是，考虑到只有登录的人应该只能更新他们的投票，处理这些问题的正确方法是什么？

我正在开发一款网页游戏，玩家可以在其中提问并投票选出最佳/最有趣的答案。游戏自动在不同阶段之间移动玩家（例如提问、回答问题、对答案进行投票......）。

每个游戏都有一个唯一的 URL。加入游戏后，当前URL 永远不会改变。这有一些缺点——主要是浏览器历史只有一个页面，因此很容易意外退出游戏，尤其是在移动设备上。重新加入很容易——用户只需重新访问游戏 URL——但这对每个人来说都不是直观的。

我的问题是随着游戏的进行更改路径/路线是否更好，例如/{gameid}/questions，或者是否有其他解决方案。

改变路线的原因

• 改进了后退按钮的行为。目前，如果玩家回击，他们会退出游戏，因为在浏览器历史记录中没有之前的页面。

  如果路线在游戏阶段之间发生变化，则回击可能会转到/{id}/answers→<code>/{id}/questions→(redirect)→<code>/{id}/answers

• 它更“惯用”——页面在不同的游戏阶段看起来完全不同，因此使用不同的 URL 是有意义的。

反对改变路线的理由

• 它不那么“惯用”！拥有不同的 URL 意味着用户可以更改它以进行导航，而游戏在任何时候都只会有一个正确的页面。任何导航到的尝试都/{id}/**将始终重定向到/{id}/{the correct stage}. 保持这种/{id}感觉更“基于资源”。

我的目标是做任何感觉直观的事情。我欢迎任何意见！