Советы для схем URL
107ASP.NET --- ASP.NET MVC 5 --- Советы для схем URL
После всего сказанного в предыдущих статьях, посвященных системе маршрутизации ASP.NET MVC, может остаться вопрос: с чего начинать проектирование собственной схемы URL?
Вы можете просто принять стандартную схему, которую генерирует среда Visual Studio, однако предоставление собственной схемы обеспечивает ряд преимуществ. В последние годы подход с URL приложения используется все более и более широко, и появилось несколько важных принципов проектирования. Следуя этим проектным шаблонам, вы улучшите удобство использования и совместимость, а также повысите поисковый рейтинг своих приложений.
Делайте URL чистыми и понятными человеку
Пользователи обращают внимание на URL в приложениях. Если вы не согласны с этим, то просто вспомните, когда вы в последний раз пытались отправить кому-то URL наподобие следующего (например ссылку на футбольный мяч, который продается в интернет-магазине):
http://www.mysite.com/Football-balls-1459/dp/1982242361/ref=la_B1341IU0SFK_l_5?ie=UTF8&qid=1589448157&sr=l-5
Отправить по электронной почте такой URL еще можно, но сообщить его по телефону будет не особенно легко. Когда этим нужно заниматься часто, в конечном счете, приходится предлагать самостоятельно найти эту страницу в интернет магазине. Было бы неплохо получать доступ к странице с помощью URL следующего вида:
http://www.mysite.com/Football/Balls/Gold-Ball
Конечно, такой URL гораздо проще продиктовать по телефону.
Ниже приведены некоторые простые рекомендации относительно того, как сделать URL дружественными к пользователям:
Проектируйте URL так, чтобы они описывали предоставляемое содержимое, а не детали реализации приложения. Применяйте /Articles/AnnualReport, а не /Website_v2/CachedContentServer/FromCache/AnnualReport.
Отдавайте предпочтение заголовкам содержимого перед идентификационными номерами. Используйте /Football/Balls/Gold-Ball, а не /Football/Balls/1459.
Если вы обязаны применять идентификационные номера (для различения элементов с одинаковыми заголовками или во избежание дополнительных запросов к базе данных необходимых для поиска элемента по его заголовку), указывайте как номер, так и заголовок (например, /Football/Balls/1459/Gold-Ball). Такой URL дольше набирать, однако он является более осмысленным для человека и способствует повышению поискового рейтинга. Приложение может просто игнорировать заголовок и отображать элемент, соответствующий идентификатору.
Не используйте расширения имен файлов для HTML-страниц (например, .aspx или .cshtml), но применяйте их для специализированных типов файлов (таких как .jpg, .pdf и .zip). Веб-браузеры не обращают внимания на расширения имен файлов, если тип MIME установлен корректно, но люди ожидают, что файлы PDF будут иметь расширение .pdf.
Создавайте осмысленную иерархию (например, /Products/Menswear/Shirts/Red), чтобы посетитель мог догадаться, как выглядит URL родительской категории.
Обеспечьте независимость от регистра символов. (Некоторым может понадобиться вводить URL, указанный на печатной странице.) По умолчанию система маршрутизации ASP.NET не чувствительна к регистру символов.
Избегайте использования знаков, кодов и символьных последовательностей. В качестве разделителя слов применяйте дефис (как в /my-great-article). Подчеркивания не являются дружественными к пользователю, а URL-кодированные пробелы выглядят либо неестественно (/my+great+article), либо вообще отвратительно (/my%20great%20article).
Не изменяйте URL. Нерабочие ссылки пагубно сказываются на бизнес-деятельности. После изменения URL продолжайте поддерживать старую схему URL насколько возможно долго через постоянные (301) перенаправления.
Будьте последовательны. Используйте в масштабах всего приложения один формат URL.
URL должны быть короткими, простыми для ввода, редактируемыми человеком и постоянными, и они должны отражать структуру сайта. Якоб Нильсен, гуру по удобству использования, дает расширенное изложение этой темы. Тим Бернерс-Ли, изобретатель Всемирной паутины, предлагает аналогичные советы.
GET и POST: выбор правильного запроса
Эмпирическое правило заключается в том, что запросы GET должны применяться для извлечения информации, предназначенной только для чтения, а запросы POST - для любой операции, которая изменяет состояние приложения. В контексте соблюдения стандартов запросы GET предназначены для безопасного взаимодействия (не имеющего побочных эффектов кроме извлечения информации), а запросы POST - для небезопасного взаимодействия (принятие решения или изменение чего-либо). Эти соглашения установлены консорциумом W3C (World Wide Web Consortium).
Запросы GET являются адресуемыми - вся информация содержится в URL, который можно добавить в закладки и ссылаться в дальнейшем.
Не используйте запросы GET для операций, которые изменяют состояние. Многие веб-разработчики научились этому на горьком опыте в 2005 г., когда в свет вышло приложение Google Web Accelerator. Это приложение выбирало с упреждением все содержимое, на которое ссылалась каждая страница, используя безопасные запросы GET, что с точки зрения протокола HTTP вполне законно. К сожалению, как оказалось, многие веб-разработчики игнорировали соглашения HTTP и размещали в своих приложениях простые ссылки вроде "удалить элемент" или "добавить в корзину". В результате наступил хаос.
В одной из компаний были уверены, что их система управления содержимым стала объектом постоянных атак со стороны злоумышленников, т.к. все содержимое оказывалось удаленным. Позже они обнаружили, что поисковый агент наткнулся на URL административной страницы и прошелся по всем ссылкам на удаление. Аутентификация способна защитить от посторонних пользователей, но не от веб-акселераторов.