Routing Templates

Các đường dẫn rất cơ bản chúng ta đã tạo ra, phần cố định và vài tham số thay đổi. Tuy nhiên, ta có thể tạo ra đường dẫn nâng cao bằng mẫu.

Trong bài trwowscn chúng ta dùng {id} để ánh xạ một phần URL vào trong tham số gọi là "id" trong phương thức của controller. Đây là một trong những mẫu đường dẫn cơ bản nhất, nhưng có thể mở rộng. Bạn có thể kết hợp chúng theo cách mà bạn muốn. Có thể kết hợp cả ID và slug như:

Đây là ví dụ về mẫu đường dẫn mà ta có thể kết hợp hai tham số [ID]/[URL_SLUG] URL:

[Route("blog/{entryId}/{slug}")]
public IActionResult Blog(int entryId, string slug)
{
    return Content($"Blog entry with ID #{entryId} requested (URL Slug: {slug})");
}

You can now reach this action using a URL like this:

/blog/153/testing-asp-mvc-routes/

"153" được đưa vào entryId, còn "testing-asp-mvc-routes" sẽ được đưa vào slug

Blog entry with ID #153 requested (URL Slug: testing-asp-mvc-routes)

Catch-all parameters

Nếu kiểm tra đường dẫn thì dấu / là không hợp lệ:

/blog/153/testing-the/routing-system/  

Lý do đơn giản là / để chia tên của thư mục. Giống như bạn đang truy cập vào hai thư mục "testing-the" và "routing-system". Khác phục bằng cách cho phép dấu / là một phần của URL slug? Chúng ta dùng cach bắt toàn bộ tham số.

Dùng dấu hoa thị * trước tham số:

[Route("blog/{entryId}/{*slug}")]
public IActionResult Blog(int entryId, string slug)
{
    return Content($"Blog entry with ID #{entryId} requested (URL Slug: {slug})");
}

Our URL from before will now allow for the forward slash in the slug parameter:

URL:  
/blog/153/testing-the/routing-system/    

Output:
Blog entry with ID #153 requested (URL Slug: testing-asp/mvc-routes)

Optional parameters

Trong ví dụ trên, cả entryId và slug đều cần - nếu bỏ qua trong URL thì định dạng đường dẫn sẽ không phù hợp và lỗi 404 xuất hiện hoặc sẽ gọi đến URL mặc định. Tuy nhiên, đôi khi bạn muốn một vài tham số là tùy chọn.

For instance, you may decide that the URL slug for your blog posts should be optional - after all, the ID is enough to identify the desired blog post and display it to the user, while the slug part is often included for SEO/readability reasons. Making the slug part of the URL optional is as simple as adding a question mark (?) to the parameter name:

[Route("blog/{entryId}/{slug?}")]
public IActionResult Blog(int entryId, string slug)
{
    return Content($"Blog entry with ID #{entryId} requested (URL Slug: {slug})");
}

You can now call the action method with a URL like this one:

/blog/153/

If you do so, the slug parameter will be NULL. This is not a problem when using it for output the way we do, but if you tried using the value for other purposes, it could result in a NullReferenceException. To remedy this, you should either check for NULL before using it, or, if it makes more sense in your case, add a default string value to the parameter (empty or non-empty) like this:

[Route("blog/{entryId}/{slug?}")]
public IActionResult Blog(int entryId, string slug = "") 
{
    ....

Reserved routing names

When creating your routes and specifying, for instance, parameter names, you should pay attention to the following words, which are reserved within the routing system and therefore shouldn't be used as names/parameter names:

• action
• area
• controller
• handler
• page

Summary

As you can see, URL routing is very flexible when using the template functionality illustrated in this article. However, sometimes a route can become TOO flexible, meaning that it might conflict with other routes in your website. For these situations, among others, you need to take more control of your routes - this can be achieved with routing constraints, which we'll discuss in the next article!