Kur*_*ucu 6 routes laravel laravel-routing laravel-5
这可能有点主观，但我认为必须存在最佳实践（甚至在Laravel应用程序方面甚至是好的设计）。谷歌搜索导致很多事情与该问题的实际观点无关。
假设我正在构建一个具有团队的Web应用程序，该团队可能包含项目，可能包含文档。
我是否应该设计工艺路线，使文档位于其所属项目的路径之内，然后位于其所属团队的路径之内，还是将其保留在顶层？
据我所知，该频谱的两端值得讨论（其他选项只是中间的灰色）：
套料
例如，可以在以下位置找到Doc C：/ teams / team-a / projects / project-b / documents / doc-c
这很容易做到，在路由文件中，我可以使用路由组来帮助保持结构整洁。我认为这对用户来说更合乎逻辑，并且也许更方便（他们可以自己制定URL！）。我担心的是我正在将复杂性导入每个页面请求中：
我是否应该在每个控制器方法的开头，对于每个路由参数都对每个资源进行门/策略检查？否则，在哪里可以抽象？
关于路由完整性，我从未见过为此进行测试的示例-那么这不是常见的方法吗？如果我们不验证路线的完整性，那么页面可能会通过修改路线来显示混合信息（例如，/ teams / team-a / projects / project-Z / documents / doc-c将在文档上显示有关项目Z的信息-c页面）。
没有嵌套
例如，可以在以下位置找到Doc C：/ documents / doc-c
在此示例中，每个资产都有其自己的基本路线，更像是我猜想的API。
不需要完整性检查，并且控制器将预先确定显示的其他资产以生成视图。
但是这个UX足够好吗？我见过的大多数网站都不这样做。
这是一个有趣的问题-正如您提到的那样，这可能有点主观，但值得讨论。
您需要指出几点，所以我将尝试分别解决。
我认为要清除的第一件事是浏览器路由与API路由。如果您要提供的API是应用程序内部的应用程序还是外部提供的公共应用程序，出于以下几个原因，我会避免使用嵌套路由：
但是，您的问题似乎确实集中在浏览器路由上。在我看来，浏览器的路线可以而且应该是任何看起来不错的东西-网址（尤其是最近这些网址）都可以视为用户界面的一部分。例如，您可能会/settings从设置页面转到设置（我希望看到），如果我要进入通知设置部分，则希望看到/settings/notifications。
这些路径可以起到UX的作用和辅助作用-它们几乎是面包屑，应该看起来像这样。
因此，我绝对会嵌套浏览器路由，而绝对不会嵌套API。
我认为您的问题的真正核心在于路线的完整性。我认为无论您是否选择嵌套，都需要假设某人正在篡改网址来检查您的权限-就像您认为用户已篡改表单输入一样。
本质上，您的路线（是否嵌套）都可以作为输入，因此您需要进行验证。路由级中间件是一种方法，但是通常太通用而无法解决任何复杂的问题，因此您可能会发现使用控制器中间件（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还是仅使用普通的旧中间件，都可能取决于项目的复杂性-但以上内容无论如何都适用-将url作为输入并相应地进行验证