Should I Nest Routes to Resources in 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.

---

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):

Nesting

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

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:

• in checking that the route has integrity (i.e., that doc-c does belong to project-b), and
• that the user has authority to access each of the nested assets all the way through the route.

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?

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).

Without Nesting

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

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.

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

回答1:

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.

Nesting vs Not nesting

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:

• resource/id format is quite standard and expressive for API's
• this makes it easier to document
• this makes it easier for the consumer app to dynamically construct API requests

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.

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

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

Route integrity

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.

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');
}

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

回答2:

This always has been a discussion between developers even the creators of Laravel have this argument, so what is the good practice?

Lately I've seen a tweet from Taylor Otwell saying that he has deprecated the nested routes section from Laravel docs because he didn't prefer it, while when you open Laracasts you see Jeffrey is implementing this concept like /series/php-testing/episodes/hello-world.

As I told it's a quiet argument and when it comes to choices like that I always do what it feels good for me. So if I were you I wouldn't nest neither teams or projects but maybe I would nest projects/documents, I don't go for nesting always.

回答3:

This might be a bit of a deviation from the original question, but I feel that Adam Wathan's Laracon US 2017 talk might be a useful resource for this discussion. (https://www.youtube.com/watch?v=MF0jFKvS4SI)

I am relatively new to development and therefore explore a lot of code bases on github. I always struggle to understand nested routes. So as a best practice I would prefer no-nesting to nesting.

Keeping stuff "CRUDY by design" as Adam calls it, one thing you achieve, imo, is simplification of route names. If I were to work in a group, that is a pattern I would prefer.

However, referring to the penultimate paragraph on your question, I struggle to understand why an integrity check is not needed.

回答4:

I've spent the last year looking at this and refining it, and stumbled upon an elegant solution recently. Nesting can be done nicely, I'm sticking to resource controllers and dot-syntax for nested route resources.

In order to enforce the route validation, I am using something like the following. There is a good answer here, which suggests explicitly binding the models in question.

So with

Route::resource('posts.comments', 'CommentsController');

You'd use

Route::bind('comment', function ($comment, $route) {
    return Comment::where('post_id', $route->parameter('post'))->findOrFail($comment);
});

This will automatically work everywhere. If required, you could test for the upstream parameter to be found, and only perform the test in those cases (e.g. to cater for routes where only a comment is specified).

回答5:

I think you should makes use of Role concepts, Route grouping , Middleware concepts to build this app

For Role related things check https://github.com/spatie/laravel-permission , a good package

Eg:

Route::group(['middleware' => ['role:super-admin']], function () {
    //
});

You can almost do any role, permission related things using above package.

Assume roles like project manager, developer.

Group your Routes based on roles & assign proper Middleware as you need.

For URL : /teams/team-a/projects/project-b/documents/doc-c

Check the Authenticated user has a role in team-a & project-b (You can check this in Middleware, Controller or custom Service provider anywhere as your need).

Also just check https://laravelvoyager.com/

Thanks