Советы для схем URL

107

После всего сказанного в предыдущих статьях, посвященных системе маршрутизации 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 должны быть короткими, простыми для ввода, редактируемыми человеком и постоянными, и они должны отражать структуру сайта. Якоб Нильсен, гуру по удобству использования, дает расширенное изложение этой темы. Тим Бернерс-Ли, изобретатель Всемирной паутины, предлагает аналогичные советы.

GET и POST: выбор правильного запроса

Эмпирическое правило заключается в том, что запросы GET должны применяться для извлечения информации, предназначенной только для чтения, а запросы POST - для любой операции, которая изменяет состояние приложения. В контексте соблюдения стандартов запросы GET предназначены для безопасного взаимодействия (не имеющего побочных эффектов кроме извлечения информации), а запросы POST - для небезопасного взаимодействия (принятие решения или изменение чего-либо). Эти соглашения установлены консорциумом W3C (World Wide Web Consortium).

Запросы GET являются адресуемыми - вся информация содержится в URL, который можно добавить в закладки и ссылаться в дальнейшем.

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

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

CodeChick.io - Задачи по программированию с автоматической проверкой
Пройди тесты
Лучший чат для C# программистов