我真的很喜欢拥有"漂亮的" URL(例如，/ Products / Edit / 1而不是/products.aspx？productID = 1)，但是对于如何让我们通过大量的变量。

例如，假设我们有一个页面，用户可以通过该页面搜索具有特定名称和特定地址附近的特定类型的所有产品。我们会使用很长的"漂亮" URL来执行此操作吗

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

或者只是诉诸使用url参数

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

解决方案

我们可以使用URL重写器或者构建自己的URL重写器。网站使用哪种语言开发？

MVC(模型视图控制器)框架是专门为解决此问题而设计的。它使用一种形式的url重写将操作重定向到页面，并仅提供我们要查找的功能。这使得处理漂亮的网址变得轻而易举。

关于URL的长度，id仍使用漂亮的url，但是URL太长可能表明我们可能要重新考虑项目的分组，如果可以，请更改商品/ {NAME} / {Address}没有中介网址部分。

MVC框架的示例可以在以下位置找到：

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

PHP http://www.phpmvc.net/

Java http://struts.apache.org/

我们有类似的URL重写，并且使用IIS 6，我们将重定向定义为：

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

这采用以下形式的网址

/ content / page / press_room，并将其设置为以下格式

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

我不确定IIS具有完整的synyax选项，但是我确定可以通过类似的方式来完成所需的操作。

我们可以在此处找到有关.NET中路由的答案：

在ASP.Net中实现动态URL重写的最佳方法是什么？

在那里，我们可以找到有关该主题的其他资源。

如前所述，最好使用HTTP Post，但是这样会使人们无法将链接发送给人们/将其添加为书签。将查询字符串留在URL中并不会太糟糕。我进行了设置，以便url字符串像这样：

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

然后，要对搜索结果进行分页，请在查询字符串之前添加页码(因此，可以根据需要自定义查询字符串。

• 第1页：http：//example.com/search/？productType = {producttype}＆name = {name}
• 第2页：http：//example.com/search/2/？productType = {producttype}＆name = {name}
• 第3页：http：//example.com/search/3/？productType = {producttype}＆name = {name}

等等...

最终，搜索之王" Google"不介意将查询字符串留在URL中，这样就不会太糟:)

我们可以获取"漂亮"的网址，但不能通过最漂亮的方式获取。

我们可以将网址设置为以下形式：

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

然后是一个mod_rewrite规则，例如：

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

这将在product_lookup文件中为我们提供2个参数：

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

然后，我们可以在product_lookup.php文件中实现一些逻辑，以循环遍历$ params`，将其拆分为" /"，并根据" _"之前的内容对其进行标记，然后在搜索正常，例如

// 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};

将参数设置为"漂亮" URL(而不是POST)可以使用户更轻松地为特定搜索添加书签。

一个实际的例子是
http：// www.property.ie / property-for-sale / dublin / ashington / price_200000-550000 / beds_1 /
用户选择的参数由" _"(价格范围和床位)表示，可以在内部将其转换为所需的任何参数格式，同时保留易于阅读的网址。

上面的代码是一个简单的示例，没有进行错误检查(输入中包含流氓定界符等)，但是应该让我们知道从哪里开始。

它还假定使用LAMP堆栈(Apache表示mod_rewrite和PHP)，但是可以使用asp.net和IIS mod_rewrite等效的代码沿同一行完成。

这个问题主要是关于URL设计的，而只是关于重写的问题。一旦将URL设计得很酷，就有许多方法可以使它们工作，包括在服务器级别重写或者使用基于URL的分派的Web框架(我认为现在大多数现代Web框架都在这样做)。

情人眼中的美丽，但我确实同意观点，即许多搜索网址都很丑陋。是什么让他们如此？我认为使URL变得丑陋的主要原因是URL中没有添加语义，而是实现细节(如(.aspx)或者其他扩展名)的结果。我的规则是，如果URL返回(X)HTML，则它不应具有扩展名，否则应具有扩展名。

在搜索的情况下，事实是标准搜索语法确实增加了含义：它指示页面是搜索，它指示参数已命名且可重新排序。丑陋主要来自？＆=字符，但实际上，我们要做的所有其他操作都是用更具吸引力的字符(例如|-/)替换这些相同的字符，但这样做的代价是使URL对希望解析它的任何软件都是不透明的例如Spider，高速缓存的代理服务器或者其他。

因此，请仔细考虑不要使用标准语法，并确保我们有充分的理由这样做。我认为，在参数具有自然顺序并且必须全部定义以使搜索有意义且紧凑的情况下，可以将其推入URL。例如，在博客URL中，我们可能具有：

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

对于分别定义2008年，2008年11月和2008年11月22日的条目的搜索。网址应该是唯一且明确的；有时人们输入/-/来缺少搜索参数，我认为这很紧凑。但是，我会避免将可能较长的参数(例如自由格式的文本查询)推入URL。
/ weblog / entries / contains / here％20is％20some％20freeform％20text％20blah％20blah并不比使用查询语法更具吸引力。

如果要使用标准查询语法，则选择有意义的参数名称可能会在某种程度上提高吸引力。 products / search？description =" blah"尽管更长，但可能比product / search？q =" blah"更好。我认为，这时收益正在递减。