laravel - 我应该在 Laravel 中嵌套资源的路由吗？

Question

这可能有点主观，但我觉得最佳实践必须存在(甚至是 Laravel 应用程序的良好设计)。谷歌搜索会导致很多与此问题中的实际要点无关的事情。

假设我正在构建一个包含团队的 Web 应用程序，其中可能有项目，也可能有文档。

我应该设计路由以使文档位于它们所属项目的路径内，然后它们位于它们所属团队的路径内，还是将事情保持在顶层？

据我所知，这个范围有两个值得讨论的端点(其他选项只是中间的灰色):

嵌套

Example, Doc C is found at: /teams/team-a/projects/project-b/documents/doc-c

这样做很容易，在路由文件中，我可以使用 route groups以帮助保持结构清洁。我认为这对用户来说更合乎逻辑，也许更方便(他们可以自己计算 URL!)。我担心的是我将复杂性导入到每个页面请求中:

检查路由是否具有完整性(即 doc-c 确实属于 project-b)，以及

用户有权在整个路由中访问每个嵌套 Assets 。

对于每个路由参数，我是否应该在每个 Controller 方法的开头对每个资源进行门/策略检查？否则，这可以从哪里抽象出来？

关于路由完整性，我从未见过对此进行测试的示例 - 这不是一种常见的方法吗？如果我们不验证路由完整性，那么页面可能会通过修改路由来显示混合信息(例如，/teams/team-a/projects/project-Z/documents/doc-c，会在 doc 上显示有关项目 Z 的信息-c 的页面)。

无嵌套

Example, Doc C is found at : /documents/doc-c

在这个例子中，每个 Assets 都有自己的基本路线，我猜更像是一个 API。

不需要完整性检查， Controller 将预先确定显示的其他 Assets 以生成 View 。

但是这样的用户体验够好吗？我见过的大多数网站都没有这样做。

Answer 1

这是一个有趣的问题 - 正如您所提到的，它可能有点主观，但值得讨论。

您触及了几点，因此我将尝试分别解决它们。

嵌套与不嵌套

在我看来，首先要弄清楚的是浏览器路由与 API 路由。如果您提供 API - 无论是在您的应用程序内部还是在公众外部，我都会出于以下几个原因避免嵌套路由:

资源/id 格式对于 API 的

来说是非常标准和富有表现力的。

这样可以更轻松地记录

这使得消费者应用程序可以更轻松地动态构建 API 请求

但是，您的问题似乎确实集中在浏览器路由上。在我看来，浏览器路由可以而且应该是任何读起来很好的东西 - url，尤其是现在，可以被视为 UI 的一部分。例如，您可以从设置页面转到设置(我希望看到 /settings )，如果我要进入通知设置部分，我希望看到 /settings/notifications .

路线对用户体验起到作用和帮助 - 它们几乎是面包屑，应该看起来如此。

因此，我肯定会为浏览器路由嵌套，而绝对不会为 API 嵌套。

路由完整性

我认为您问题的真正核心是关于路线完整性。我认为无论您是否选择嵌套，您都需要在假设有人篡改 url 的情况下检查您的权限 - 与您假设用户篡改表单输入的方式相同。

本质上，您的路由(嵌套与否)充当输入，您需要对其进行验证。路由级中间件是一种方法，但通常过于通用而无法解决任何复杂的问题，因此您可能会发现使用 Controller 中间件 ( https://laravel.com/docs/5.7/controllers#controller-middleware ) 更容易解决它。

因此，您可以执行以下操作:

public function __construct()
{
    $this->middleware('auth');

    $this->middleware('canViewProject')->only('show');

    $this->middleware('canEditProject')->except('store');
}

无论您是使用 Gates、Policies 还是只是简单的旧中间件，都可能取决于项目的复杂性 - 但无论如何以上都适用 - 将 urls 视为输入并进行相应的验证