ASP.NET MVC 4

ASP.NET MVC 4

Адам Фриман

Лучшие примеры URL схемы

После всего этого вам, наверное, остается только гадать, с чего начать, чтобы создать собственную URL схему. Вы можете просто принять схему по умолчанию, которую Visual Studio генерирует для вас, но есть некоторые преимущества в создании чего-то своего.

В последние годы дизайн URL стали воспринимать довольно серьезно, и появилось несколько важных принципов проектирования. Если вы последуете этим паттернам проектирования, вы улучшите юзабилити и совместимость, а также поднимите поисковой рейтинг вашего приложения.

Делайте свои URL чистыми и дружелюбными

Пользователи обращают внимание на URL в приложениях. Если вы не согласны, то просто вспомните последний раз, когда вы пытались послать кого-нибудь на URL от Amazon. Вот URL для этой книги:

http://www.amazon.com/Pro-ASP-NET-MVC-Professional-
Apress/dp/1430242361/ref=la_B001IU0SNK_1_5?ie=UTF8&qid=1349978167&sr=1-5

Такую ссылку не особо приятно отправлять даже по электронной почте, но попробуйте прочитать это по телефону. Когда нам нужно было это сделать, мы просто посмотрели номер ISBN и попросили звонившего самого найти книгу. Было бы неплохо, если бы мы могли получить доступ к книге с URL вроде этого:

http://www.amazon.com/books/pro-aspnet-mvc4-framework

Это тот вид URL, который мы могли бы продиктовать по телефону, и он не выглядит так, как будто мы что-то уронили на клавиатуру при составлении сообщения электронной почты.

Примечание

Чтобы внести ясность, мы очень уважаем Amazon, который продает больше наших книг, чем все остальные, вместе взятые. Мы знаем, что каждый член команды Amazon является поразительно умным и красивым человеком. И никто из них не является мелочным, чтобы прекратить продажи наших книг из-за чего-то настолько незначительного, как критика их URL формата. Мы любим Amazon. Мы обожаем Amazon. Мы просто хотим, чтобы они поправили свои URL.

Вот несколько советов по созданию дружелюбных URL:

  • Создавайте URL, описывая их содержание, а не внося информацию о реализации вашего приложения. Используйте /Articles/AnnualReport, а не /Website_v2/CachedContentServer/FromCache/AnnualReport.
  • Предпочитайте названия номерам ID. Используйте /Articles/AnnualReport, а не /Articles/2392. Если вы должны использовать номер ID (чтобы различать элементы с одинаковыми названиями, или чтобы избежать дополнительных запросов к базе данных, необходимых для нахождения элемента по его названию), делайте это вот так: /Articles/2392/AnnualReport (используйте и название, и ID). Это займет больше времени, но это понятно пользователям и улучшает рейтинг в поисковых системах. Ваше приложение может просто игнорировать название и отображать элемент, соответствующий данному ID.
  • Не используйте расширения имен файлов для HTML страниц (например, .aspx or .mvc), но используйте их для специализированных типов файлов (например, .jpg, .pdf и .zip). Веб-браузеры не сильно заботятся о расширениях имен файлов, если надлежащим образом установить MIME тип, но люди все еще ожидают PDF файлы на конце с .pdf.
  • Придавайте смысловую иерархию (например, /Products/Menswear/Shirts/Red), чтобы ваш пользователь мог понять, какой URL относится к родительской категории.
  • Не учитывайте регистр (пусть ваш URL будет регистронезависимым). Роутинговая система ASP.NET по умолчанию не учитывает регистр.
  • Избегайте символов, кода и последовательности символов. Если вы хотите разделить слова, используйте дефисы (как в /my-great-article). Подчеркивания недружелюбны, а закодированные пробелы странные (/my+great+article) или отвратительные (/my%20great%20article).
  • Не меняйте URL. Неработающие ссылки равны потере бизнеса. Если все же вы меняете URL, продолжайте поддерживать старую URL схему как можно дольше через перенаправление 301.
  • Будьте последовательны. Придерживайтесь одного URL формата во всем приложении.

URL должны быть краткими, легко набираемыми, редактируемыми (чтобы пользователь мог сам работать с URL) и надежными, также они должны визуализировать структуру сайта. Якоб Нильсен, гуру юзабилити, развивает эту тему на http://www.useit.com/alertbox/990321.html. Тим Бернерс-Ли, изобретатель Интернета, дает подобный совет (см. http://www.w3.org/Provider/Style/URI).

GET и POST: выберите правильный

Негласное правило гласит, что запросы GET следует использовать для получения информации «только для чтения» (read-only), в то время как POST запросы должны быть использованы для любой операции, которая изменяет состояние приложения. В терминах стандартизации, GET запросы служат для безопасного взаимодействия (только для получения информации), а POST запросы для небезопасного взаимодействия (принятие решения или изменение чего-то). Эти соглашения устанавливаются World Wide Web Consortium (W3C), на http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html.

GET запросы являются адресуемыми: вся информация содержится в URL, так что можно создавать закладки и делать ссылки на эти адреса.

Не используйте GET запросы для операций, изменяющих состояние. Многие веб-разработчики узнали это на собственном горьком опыте в 2005 году, когда был публично выпущен Google Web Accelerator. Это приложение прошло по всему контенту, для которого были назначены ссылки, что является законным для HTTP GET запросов, потому что они должны быть безопасными. К сожалению, многие веб-разработчики проигнорировали HTTP соглашение и разместили простые ссылки для "удалить" или "добавить в корзину" в своих приложениях. Начался хаос.

Одна из компаний посчитала, что их система управления контентом была целю повторяющихся атак, потому что все содержимое снова и снова удалялось. Позже они выяснили, что поисковой робот натолкнулся на URL административной страницы и прошел по всем ссылкам для удаления. Аутентификация может защитить вас от этого, но она не сможет защитить вас от поисковых роботов (краулеров).

или RSS канал: Что новенького на smarly.net