Как вы структурируете свои URL-маршруты?

Мне нравятся RESTful, удобные для пользователя и взломанные URL-адреса.

Что это значит? Начнем с удобных URL. Для меня удобный URL-адрес — это что-то легкое для ввода и легкое для запоминания, /Default.aspx?action=show&userID=140 не отвечающее ни одному из этих требований. Однако такой URL, как «/users/troethom», кажется логичным.

Это приводит к следующему пункту. URL, который можно взломать, – это URL-адрес, который пользователь может изменить, но при этом получить результат. Если URL-адрес можно взломать, а URL-адрес моего профиля — /users/troethom, было бы безопасно удалить мое имя пользователя, чтобы получить список пользователей (/users).

Использование URL-адресов RESTful очень похоже на идеи, лежащие в основе других моих предложений. Вы разрабатываете URL-адреса для пользователя, а не для машины, и поэтому URL-адрес должен относиться к контенту, а не к технической части вашего сайта. URL-адрес «/users» имеет больше смысла, чем «/users/list», а URL-адрес «/category/programming/javascript» (представление подкатегории «javascript» в категории «programming» лучше, чем «/category/show /12´.

Действительно, пропустить идентификаторы сложнее, но в моем мире это стоит затраченных усилий.

Также обратитесь к разделу "Понимание URI" в документе W3C "Общие проблемы реализации HTTP". В нем есть список распространенных ошибок при разработке URI. Еще один хороший ресурс — находчивые и взломанные поисковые URL.

Вы можете взглянуть на вопрос "Дружественная схема URL-адресов?".

В частности, Larry.Smithmier answer содержит список распространенных схем URL-адресов при использовании MVC в ASP.NET. .

Кроме того, вы можете рассмотреть возможность использования разных глаголов для повторного использования одних и тех же маршрутов для разных действий. Например, GET-запрос к «Products/Edit/45» отобразит редактор продукта, тогда как POST-запрос на тот же URL-адрес обновит продукт. Для этого можно использовать атрибут AcceptVerb:

[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 });
}

Билл де Ора написал очень хорошее эссе под названием Критерии сопоставления веб-ресурсов для фреймворков это стоит прочесть.

Чтобы добавить к комментариям троэтома, RESTful обычно также означает, что, например, для создания нового пользователя вы должны ПОСТАВИТЬ представление в /users/newusername

RESTful в основном использует 5 стандартных методов HTTP (GET, PUT, POST, DELETE, HEAD) для управления/доступа к контенту.

Хорошо, это непросто для веб-браузера, но вы всегда можете использовать перегруженный POST (отправить в /users/username с представлением пользователя, чтобы изменить некоторые детали и т. д.).

Это хороший способ сделать что-то, я бы рекомендовал прочитать RESTFul Веб-сервисы для лучшего понимания :D (и это чертовски хорошая книга!)

Я видел два основных общепринятых подхода к этой теме...

Один описан в документации проекта MvcContrib.

а другой описан в запись в блоге Стивена Вальтера (что я лично предпочитаю).