¿Cómo estructura sus rutas URL?

Question

¿Existe algún patrón específico que los desarrolladores sigan generalmente?Nunca antes lo había pensado mucho en mis aplicaciones web, pero el motor de enrutamiento ASP.NET MVC prácticamente te obliga a al menos tenerlo en cuenta.

Hasta ahora me ha gustado la estructura controlador/acción/índice (p. ej.Products/Edit/1), pero tengo problemas con URL más complejas.

Por ejemplo, digamos que tiene una página que enumera todos los productos que un usuario tiene en su cuenta.¿Como lo harias?Se me ocurren las siguientes posibilidades para una página de listado y una página de edición:

1. Usuario/{id de usuario}/Productos/Lista, Usuario/{id de usuario}/Productos/Editar/{id de producto}
2. Usuario/{id de usuario}/Productos, Usuario/{id de usuario}/Productos/{id de producto}
3. ¿Productos?UserID={id de usuario}, Productos/Editar/{id de producto}

Estoy seguro de que hay muchos otros que me estoy perdiendo.¿Algún consejo?

Answer 1

Me gustan las URL RESTful, fáciles de usar y pirateables.

¿Qué quiere decir esto?Empecemos con URL fáciles de usar.Para mí, una URL fácil de usar es algo fácil de escribir y fácil de recordar. /Default.aspx?action=show&userID=140 no cumple ninguno de estos requisitos.Sin embargo, una URL como `/users/troethom´ parece lógica.

Esto lleva al siguiente punto.A URL pirateable es una URL que el usuario puede modificar y aun así recibir un resultado.Si la URL se puede piratear y la URL de mi perfil es /users/troethom Sería seguro eliminar mi nombre de usuario para obtener una lista de usuarios (/users).

Usando URL REST Es bastante similar a las ideas detrás de mis otras sugerencias.Está diseñando URL para un usuario y no para una máquina y, por lo tanto, la URL debe estar relacionada con el contenido y no con el back-end técnico de su sitio.Una URL como ´/usuarios´ tiene más sentido que ´/usuarios/lista´ y una URL como ´/categoría/programación/javascript´ (representar la subcategoría 'javascript' en la categoría 'programación' es mejor que ´/categoría/show /12´.

De hecho, es más difícil omitir las identificaciones, pero en mi mundo vale la pena el esfuerzo.

Consulta también la sección Comprender los URI sobre los problemas comunes de implementación de HTTP del W3C.Tiene una lista de errores comunes al diseñar URI.Otro buen recurso es URL de búsqueda ingeniosas versus pirateables.

Answer 2

Quizás quieras echarle un vistazo a la pregunta "¿Esquema de URL amigable?".

Particularmente, La respuesta de Larry Smithier proporcionó una lista de esquemas de URL comunes cuando se usa MVC en ASP.NET.

Answer 3

Además, puedes considerar usar diferentes verbos para reutilizar las mismas rutas para diferentes acciones.Por ejemplo, una solicitud GET a "Productos/Editar/45" mostraría el editor del producto, mientras que una POST a la misma URL actualizaría el producto.Puede utilizar el atributo AcceptVerb para lograr esto:

[AcceptVerb("GET")]
public ActionResult Edit(int id)
{
    ViewData["Product"] = _products.Get(id);
    return View();
}

[AcceptVerb("POST")]
public ActionResult Edit(int id, string title, string description)
{
    _products.Update(id, title, description);
    TempData["Message"] = "Changes saved successfully!";

    return RedirectToAction("Edit", new { id });
}

Answer 4

Bill de hÓra escribió un muy buen ensayo titulado Criterios de mapeo de recursos web para marcos. Vale la pena leerlo.

Answer 5

Para agregar a los comentarios de troethom, RESTful generalmente también significa que, por ejemplo, para crear un nuevo usuario, PONERÍA una representación en /users/newusername

RESTful básicamente utiliza los 5 métodos HTTP estándar (GET, PUT, POST, DELETE, HEAD) para controlar/acceder al contenido.

Ok, esto no es fácil para un navegador web, pero siempre puedes usar POST sobrecargado (publicar en /users/username con una representación de un usuario para cambiar algunos de los detalles, etc.

Es una buena forma de hacer las cosas, recomiendo leer. Servicios web RESTful para comprenderlo mejor :D (¡y es un libro muy bueno!)

Answer 6

He visto dos formas principales aceptadas de abordar este tema...

Uno se describe en el Documentación del proyecto MvcContrib

y el otro se describe en un entrada de blog de Stephen Walther (que personalmente prefiero).