martes, 22 de enero de 2013
Hace poco veíamos que el nuevo sistema de routing usado por proyectos MVC 4 permitía una cierta configuración del formato de URL generadas por la aplicación al usar helpers como
Pues bien, al igual que en ese caso, en los proyectos que usen la última versión del ensamblado
Pero, ¿por qué tendríamos que añadir una barra al final de las URL?
Es cierto que, siguiendo las tradiciones y buenas costumbres de siempre, una URL debería acabar en una barra si no apunta a un archivo con objeto de facilitar la vida al servidor. Una petición a la dirección servidor.com/algo es ambigua porque el servidor, a priori, no puede conocer si el recurso solicitado "algo" es un archivo o un directorio; si, en cambio, la petición se realiza hacia servidor.com/algo/ queda más claro que lo que se pretende es obtener el contenido de una carpeta, y en teoría podría agilizarse el proceso de búsqueda del recurso.
No he encontrado tampoco directrices que indiquen claramente en qué afecta la aparición de esa terminación en la respuesta que debe enviar el servidor. Podemos encontrar servidores que ante una petición como servidor.com/algo retornan el mismo recurso que si la URL incluyera la barra final; en otros, en cambio, se opta por retornar una redirección hacia servidor.com/algo/ (con la barra) con objeto de indicar al cliente que "esa dirección es la buena" y evitar contenidos duplicados (el mismo contenido accesible desde distintas URL). Esto último podéis comprobarlo creando una aplicación web cualquiera y accediendo a localhost:xxx/content mientras trazáis las peticiones con Fiddler o las developer tools.
En aplicaciones ASP.NET en las se usa el sistema de routing, donde no existe el concepto "directorio" como tal, el uso de estas barras no tienen demasiado sentido. Por ejemplo, en MVC las peticiones se mapean contra acciones en un controlador; en la práctica, da igual si una URL acaba o no con una barra, puesto que será procesada por la misma acción y retornará el mismo resultado.
Por tanto, con este tipo de sistemas probablemente la elección se trate más de una cuestión de gustos que otra cosa. Simplemente va de decidir un estilo y ceñirse a él en toda la aplicación; y si lo que elegimos es acabar las URL con barras, ya sabemos que el sistema de routing de ASP.NET lo soporta de serie :-)
Por mi parte, hasta ahora nunca he usado las barritas en las URL y, salvo que encuentre algún buen motivo, creo que seguiré sin hacerlo.
Y vosotros, ¿qué opináis del tema? ¿Barra sí o barra no? (Y no me refiero a las de los bares ;-P)
Publicado en: Variable not found.
Url.Action()
o Html.ActionLink()
, y cómo usando una simple línea de código podíamos hacer que las rutas se generaran usando sólo minúsculas.Pues bien, al igual que en ese caso, en los proyectos que usen la última versión del ensamblado
System.Web.Routing
, por ejemplo si compilamos aplicaciones Webforms, MVC 3 o 4 para .NET 4.5, también es posible hacer que las URLs generadas acaben con una barra inclinada estableciendo a true
la propiedad AppendTrailingSlash
:public static void RegisterRoutes(RouteCollection routes) { routes.IgnoreRoute("{resource}.axd/{*pathInfo}"); routes.AppendTrailingSlash = true; routes.MapRoute( name: "Default", url: "{controller}/{action}/{id}", defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional } ); }La siguiente tabla muestra algunos ejemplos de cómo afecta el valor de esta propiedad a la hora de generar una ruta:
Instrucción | AppendTrailingSlash | |
true | false | |
Url.Action("About", "Home") | /Home/About/ | /Home/About |
Url.Action("Edit", "Product", new {id = 1}) | /Product/Edit/1/ | /Product/Edit/1 |
Url.Action("Edit", "Product", new {id = 1, x=2}) | /Product/Edit/1/?x=2 | /Product/Edit/1?x=2 |
Pero, ¿por qué tendríamos que añadir una barra al final de las URL?
Es cierto que, siguiendo las tradiciones y buenas costumbres de siempre, una URL debería acabar en una barra si no apunta a un archivo con objeto de facilitar la vida al servidor. Una petición a la dirección servidor.com/algo es ambigua porque el servidor, a priori, no puede conocer si el recurso solicitado "algo" es un archivo o un directorio; si, en cambio, la petición se realiza hacia servidor.com/algo/ queda más claro que lo que se pretende es obtener el contenido de una carpeta, y en teoría podría agilizarse el proceso de búsqueda del recurso.
No he encontrado tampoco directrices que indiquen claramente en qué afecta la aparición de esa terminación en la respuesta que debe enviar el servidor. Podemos encontrar servidores que ante una petición como servidor.com/algo retornan el mismo recurso que si la URL incluyera la barra final; en otros, en cambio, se opta por retornar una redirección hacia servidor.com/algo/ (con la barra) con objeto de indicar al cliente que "esa dirección es la buena" y evitar contenidos duplicados (el mismo contenido accesible desde distintas URL). Esto último podéis comprobarlo creando una aplicación web cualquiera y accediendo a localhost:xxx/content mientras trazáis las peticiones con Fiddler o las developer tools.
En aplicaciones ASP.NET en las se usa el sistema de routing, donde no existe el concepto "directorio" como tal, el uso de estas barras no tienen demasiado sentido. Por ejemplo, en MVC las peticiones se mapean contra acciones en un controlador; en la práctica, da igual si una URL acaba o no con una barra, puesto que será procesada por la misma acción y retornará el mismo resultado.
Por tanto, con este tipo de sistemas probablemente la elección se trate más de una cuestión de gustos que otra cosa. Simplemente va de decidir un estilo y ceñirse a él en toda la aplicación; y si lo que elegimos es acabar las URL con barras, ya sabemos que el sistema de routing de ASP.NET lo soporta de serie :-)
Por mi parte, hasta ahora nunca he usado las barritas en las URL y, salvo que encuentre algún buen motivo, creo que seguiré sin hacerlo.
Y vosotros, ¿qué opináis del tema? ¿Barra sí o barra no? (Y no me refiero a las de los bares ;-P)
Publicado en: Variable not found.
Estos contenidos se publican bajo una licencia de Creative Commons