URL bonitas para las páginas de búsqueda

Question

Me encantan las URL "bonitas" (por ejemplo, /Products/Edit/1 en lugar de /products.aspx?productID=1), pero no sé cómo hacer esto para las páginas que le permiten buscar por un gran número de variables.

Por ejemplo, supongamos que tiene una página que le permite al usuario buscar todos los productos de un tipo determinado con un nombre determinado y cerca de una dirección específica. ¿Quieres hacer esto con muy largas URLs "bonito"

/Products/Search/Type/{producttype}/Name/{name}/Address/{address} 

o simplemente recurrir al uso de URL params

/Products/Search?productType={producttype}&name={name}&address={address} 

Answer 1

Se puede usar un re-escritura de URL o construir su propia. ¿En qué idioma se desarrolló su sitio?

Answer 2

El marco MVC (Model View Controller) está diseñado específicamente para abordar este problema. Utiliza una forma de reescritura de URL para redirigir acciones a páginas y proporciona solo la funcionalidad que está buscando. Hace que manejar urls bonitas sea muy fácil.

Con respecto a la longitud de las URL, el ID aún usa URL bonitas, pero una URL particularmente larga puede ser una indicación de que es posible que desee reconsiderar su agrupación de los elementos, modifique la clasificación si lo hace Products/{NAME}/{Address} sin partes de url intermedias.

Ejemplos del marco MVC se pueden encontrar en:

.Net - http://www.asp.net/mvc/

PHP - http://www.phpmvc.net/

Java - http://struts.apache.org/

Answer 3

Tenemos una URL similar reescritura, y el uso de IIS 6, tenemos la redirección definida como:

/content.aspx?url=$S & $ P

Esto toma una dirección URL de la forma

/content/página/press_room y lo hace en el formato

/content.aspx/url=/page/pressroom &

No estoy seguro de las opciones synyax completas que tiene IIS, pero estoy seguro de que lo que desea se puede hacer de forma similar.

Answer 4

puede encontrar una respuesta acerca de enrutamiento en .NET aquí:

What is the best method to achieve dynamic URL Rewriting in ASP.Net?

No se pueden encontrar diferentes recursos sobre el tema.

Answer 5

Como se mencionó anteriormente, usar HTTP Post sería lo mejor, pero luego se pierde la posibilidad de que las personas envíen el enlace a personas/marcarlo como favorito. Dejar la cadena de consulta en la URL no va a ser tan malo.Lo tengo configurado para que la cadena de URL es la siguiente:.

http://example.com/search/?productType={producttype}&name={name}&address={address}

Y luego para paginar los resultados de la búsqueda se suman en el número de la página antes de que la cadena de consulta (por lo que la cadena de consulta es personalizable si es necesario

• Página 1: http://example.com/search/?productType= {} Producttype & name = {nombre}
• Página 2: http://example.com/search/2/?productType= {} Producttype & name = {nombre}
• Página 3: http://example.com/search/3/?productType= {} Producttype & name = {nombre}

etc ...

Al final del día - el rey de búsqueda 'Google' No me importa dejar la cadena de consulta en la URL por lo que no puede ser tan malo :)

Answer 6

puede obtener las direcciones URL "bonita", pero no a través de los más bonitos de los medios ..

puede configurar su url para ser algo como:

/Products/Search/Type/{producttype}/Name_{name}/Address_{address} 

A continuación, un mod_rewrite regla algo como:

RewriteRule ^Products/Search/Type/([a-z]+)(.*)?$ product_lookup.php?type=$1&params=$2 [NC,L] 

Esto le dará 2 parámetros en el archivo de product_lookup:

$type = {producttype} 
$params = "/Name_{name}/Address_{address}" 

A continuación, puede aplicar un poco de lógica en su archivo product_lookup.php a pasar por $params, dividirlo en "/", ponerlo en token de acuerdo con lo que sea antes del "_", y luego usar el pa resultante los rameters en su búsqueda son normales, p.

// Split request params first on /, then figure out key->val pairs 
$query_parts = explode("/", $params); 
foreach($params as $param) 
{ 
    $param_parts = explode("_", $param); 
    // Build up associative array of params 
    $query[$param_parts[0]] = $param_parts[1]; 
} 
// $query should now contain the search parameters in an assoc. array, e.g. 
// $query['Name'] = {name}; 

Tener los parámetros como direcciones URL "bonitas" en lugar de POST permite a los usuarios marcar búsquedas particular, con mayor facilidad.

Un ejemplo de esto en acción es http://www.property.ie/property-for-sale/dublin/ashington/price_200000-550000/beds_1/ - params seleccionados por el usuario se denotan por el "_" (rango de precio y camas) que puede ser traducido internamente en cualquier formato parámetro que necesita, mientras se mantiene una buena url legible .

El código anterior es un ejemplo trivial sin comprobación de errores (delimitadores deshonestos, etc. en la entrada), pero debería darle una idea de por dónde empezar.

También asume una pila LAMP (Apache para mod_rewrite y PHP) pero podría hacerse en la misma línea usando asp.net y an IIS mod_rewrite equivalent.

Answer 7

Esta pregunta trata principalmente sobre el diseño de URL y solo de manera incidental sobre la reescritura. Una vez que haya diseñado sus URL para que sean cool, hay muchas maneras de hacer que funcionen, incluida la reescritura a nivel de servidor o el uso de un marco web que hace un despacho basado en URL (creo que los marcos web más modernos lo hacen actualmente).

La belleza está en el ojo del espectador, pero estoy de acuerdo con usted en que muchas URL de búsqueda son feas. ¿Qué los hace así? Creo que lo principal que hace que las URL sean feos es cruxt en la URL que no agrega significado semántico sino que es el resultado de un detalle de implementación, como (.aspx) u otras extensiones. Mi regla es que si una URL devuelve (X) HTML que no debería tener una extensión, de lo contrario debería hacerlo.

En el caso de una búsqueda, el hecho es que la sintaxis de búsqueda estándar agrega significado: indica que la página es una búsqueda, indica que los argumentos son nombrados y reordenados. La fealdad proviene principalmente de la? & = caracteres, pero realmente cualquier otra cosa que haga será reemplazar estos mismos caracteres con caracteres más atractivos como | - /, pero a costa de hacer que la URL sea opaca para cualquier software que desee analizarlo como una araña, un proxy de almacenamiento en caché servidor, o algo más.

Por lo tanto, piense detenidamente sobre no utilizar la sintaxis estándar y asegúrese de tener una buena razón para hacerlo. Creo que en el caso en que sus argumentos tengan un orden natural y deben definirse todos para que la búsqueda tenga sentido y son compactos, puede insertarlos en la URL. Por ejemplo, en una URL del blog que pueda tener:

/weblog/entries/2008 
/weblog/entries/2008/11 
/weblog/entries/2008/11/22 

para definir una búsqueda de las entradas a partir de 2008, noviembre de 2008, y el 22 de noviembre de 2008, respectivamente. Tus URL deben ser únicas e inequívocas; a veces la gente pone en/-/para los parámetros de búsqueda faltantes, que creo que es bastante compacto. Sin embargo, evitaría presionar parámetros potencialmente largos, como una consulta de texto de forma libre, en la URL. /weblog/entries/containing/here% 20is% 20some% 20freeform% 20text% 20blah% 20blah no es más atractivo que usar la sintaxis de la consulta.

Si va a utilizar la sintaxis de consulta estándar, elegir nombres de argumento que tengan sentido podría mejorar el atractivo, de alguna manera. products/search? description = "blah", aunque es más largo, es probablemente mejor que products/search? q = "blah". En este punto, está disminuyendo el rendimiento, creo.