我应该在Laravel中嵌套通往资源的路线吗? [英] Should I Nest Routes to Resources in Laravel?

问题描述

这可能有点主观，但是我认为必须存在最佳实践(甚至在Laravel应用程序方面甚至是好的设计).谷歌搜索导致很多事情与该问题的实际观点无关.

This may be a little subjective, but I feel that best-practice must exist (or even good design when it comes to Laravel apps). Googling results in lots of things that are not to do with the actual points in this question.

说我正在构建一个具有团队的Web应用程序，该团队可能包含项目，可能包含文档.

Say I am building a web application that has teams, which may have projects, which may have documents.

我应该设计路径，使文档位于其所属项目的路径之内，然后位于其所属团队的路径之内，还是将其保留在顶层?

Should I design the routing so that documents are within the path of the projects they belong to, which are then within the path of the teams they belong to, or keep things at a top level?

据我所知，该频谱的两端值得讨论(其他选项只是中间的灰色):

As far as I can tell, there are two ends to this spectrum that are worth discussing (other options are just the grey in-between):

嵌套

例如，可以在以下位置找到Doc C:/teams/team-a/projects/project-b/documents/doc-c

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

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

It is easy to do this, and in the routing file, I can use route groups to help keep the structure clean. I think it's more logical and perhaps more convenient for the user (they can work out URLs for themselves!). My concerns are that I am importing complexity into each page request:

• 检查路由是否完整(即doc-c确实属于project-b)，并且
• 用户有权通过路径一直访问每个嵌套资产.

我应该在每个控制器方法的开头，对于每个路由参数，对每个资源进行门/策略检查吗?否则，可以在哪里抽象呢?

Should I be putting gates/policy checks for every resource at the beginning of each controller method, for every route parameter? Otherwise, where can this be abstracted?

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

And regarding route integrity, I've never seen examples testing for this - so is this not a common approach? If we don't verify route integrity, then a page could show mixed information by hacking the route (e.g.,/teams/team-a/projects/project-Z/documents/doc-c, would show info about project Z on doc-c's page).

无嵌套

例如，可在以下位置找到Doc C:/documents/doc-c

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

在此示例中，每个资产都有其自己的基本路线，更像是我猜想的API.

In this example, every asset would have its own base route, more like an API I guess.

不需要完整性检查，并且控制器将预先确定显示的其他资产以生成视图.

No integrity checks required, and the controller would pre-determine the other assets shown to generate the view.

但是这个UX是否足够好?我见过的大多数网站都不这样做.

But is this UX good enough? The majority of websites I've seen do not do this.

推荐答案

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

This is an interesting question - as you mentioned, it may be a little subjective, but worth the discussion.

您谈到了几点，所以我将尝试分别解决.

You touch on a few points, so I will attempt to address them separately.

我认为要清除的第一件事是浏览器路由与API路由.如果您是在应用程序内部或外部提供API，则出于以下几个原因，我会避免使用嵌套路由:

First thing to clear up in my opinion is browser routes versus API routes. If you are providing an API - either internally to your app or externally to the public, I would avoid nested routes for a few reasons:

• 资源/ID格式非常标准，可表达API
• 这使记录文档变得更加容易
• 这使消费者应用更轻松地动态构造API请求

但是，您的问题似乎确实集中在浏览器路由上.在我看来，浏览器的路线可以而且应该很容易阅读-网址(尤其是最近这些日子)​​可以视为用户界面的一部分.例如，您可以从设置页面转到设置(我希望看到/settings)，如果我要进入 通知设置部分，则希望看到.

However, your question does seem to focus on the browser routes. In my opinion browser routes can and should be whatever reads nicely - the url, especially these days, can be considered as part of the UI. For example, you may go to settings (and I would expect to see /settings), from the settings page, if I were to go into the notifications settings section, I would expect to see /settings/notifications.

这些路由在UX上起作用并提供帮助-它们几乎是一个面包屑，应该看起来像这样.

The routes act and assist with UX - they are almost a breadcrumb and should look as such.

因此，我绝对会嵌套浏览器路由，而绝对不会嵌套API.

So, I would definitely nest for browser routes, and would definitely not for APIs.

我认为您的问题的真正核心在于路线的完整性.我认为无论您是否选择嵌套，都需要假设某人正在篡改url来检查您的权限-就像您认为用户已篡改表单输入一样.

The real heart of your question I think is about the route integrity. I think regardless if you choose to nest or not you need to be checking your permissions with the assumption that someone is tampering with the urls - the same way you assume that the user has tampered with the form input.

基本上，您的路线(是否嵌套)都将作为输入，您需要进行验证.路由级中间件是一种方法，但是通常太通用而无法解决任何复杂的问题，因此您可能会发现使用控制器中间件来解决它更容易( https://laravel.com/docs/5.7/controllers#controller-middleware ).

Essentially your routes (nested or not) act as input, and you will need to validate that. Route level middleware is one approach, but is often too generic to solve anything complex so you may find it easier to tackle it with controller middleware (https://laravel.com/docs/5.7/controllers#controller-middleware).

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

So you may do something like:

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

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

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

无论您使用Gates，Policy还是仅使用普通的旧中间件，都可能取决于项目的复杂性-但以上内容适用，无论如何-将url作为输入并相应地进行验证

Whether you use Gates, Policies or just plain old middleware will probably depend on the complexity of the project - but the above applies regardless - treat the urls as input and validate accordingly

这篇关于我应该在Laravel中嵌套通往资源的路线吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！