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

Question

Существует ли какая-то особая схема, которой обычно следуют разработчики? Я никогда не задумывался об этом раньше в своих веб-приложениях, но механизм маршрутизации ASP.NET MVC в значительной степени заставляет вас хотя бы принять это во внимание.

Пока мне понравилась структура контроллер / действие / индекс (например, Products / Edit / 1), но я борюсь с более сложными URL-адресами.

Например, допустим, у вас есть страница со списком всех продуктов, которые пользователь имеет в своей учетной записи. Как бы вы это сделали? Вдобавок ко всему, я могу подумать о следующих возможностях для страницы списка и страницы редактирования:

1. Пользователь / {идентификатор пользователя} / Продукты / Список, Пользователь / {идентификатор пользователя} / Продукты / Редактировать / {идентификатор продукта}
2. Пользователь / {идентификатор пользователя} / Продукты, Пользователь / {идентификатор пользователя} / Продукты / {идентификатор продукта}
3. Продукты? Идентификатор пользователя = {идентификатор пользователя}, Продукты / Изменить / {Идентификатор продукта}

Я уверен, что есть много других, по которым я скучаю. Любой совет?

Answer 1

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

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

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

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

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

Также обратитесь к в разделе «Общие сведения о URI» о распространенных проблемах реализации W3C в HTTP. У него есть список распространенных ошибок при разработке URI. Еще один полезный ресурс - Находчивые против взломанных URL-адресов поиска .

Answer 2

Возможно, вы захотите взглянуть на вопрос " Friendly url схема? ".

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

Answer 3

Также вы можете рассмотреть возможность использования разных глаголов для повторного использования одних и тех же маршрутов для разных действий. Например, запрос 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 });
}

Answer 4

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

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

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

Answer 5

Чтобы добавить к комментариям troethom, RESTful, как правило, также означает, что, например, для создания нового пользователя вы должны поместить представление в / users / newusername

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

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

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

Answer 6

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