Вопрос

Я студент веб-разработки (и колледж), поэтому прошу прощения, если это звучит наивно и оскорбительно, я определенно не имел в виду это.Мой опыт был связан с PHP, и с небольшим проектом на горизонте (прославленный календарь смен) я надеялся изучить одну из платформ более высокого уровня, чтобы облегчить нагрузку на код.До сих пор я рассматривал CakePHP Symfony Django и Rails.

В PHP URL-адреса очень просто сопоставлялись с файлами, и это «просто работало».Для сервера это было быстро и интуитивно понятно.Но во всех этих средах существует склонность «украшать» URL-адреса, заставляя их сопоставляться с разными функциями и перенаправлять параметры в разные переменные в разных файлах.

В книге «Путь Rails», которую я читаю, признается, что это очень медленно и является причиной большинства проблем с производительностью в крупных проектах.Мой вопрос: «Почему он вообще?»?Есть ли какой-то конкретный момент в парадигме URL-карт в файл (или mod_rewrite в один файл), который требует регулярных выражений и сложных схем маршрутизации?Я что-то упускаю, не используя их?

Заранее спасибо!

Это было полезно?

Решение

  • URL-адреса должны легко запоминаться и произноситься.И пользователь должен знать, чего ожидать, когда он увидит этот URL-адрес.Сопоставление URL-адреса непосредственно с файлом не всегда позволяет это сделать.
  • Возможно, вы захотите использовать разные URL-адреса для одной и той же или, по крайней мере, похожей отображаемой информации.Если ваш сервер заставляет вас использовать сопоставление 1 URL <-> 1 файла, вам необходимо создать дополнительные файлы, все их функции которых заключаются в перенаправлении на другой файл.Или вы используете такие вещи, как mod_rewrite что не проще, чем сопоставление URL-адресов Rails.
  • В одном из моих приложений я использую URL-адрес, который выглядит как http://www.example.com/имя пользователя/некоторые дополнительные вещи/.Это также можно сделать с помощью mod_rewrite, но, по крайней мере, для меня проще настроить URL-адреса в проекте django, чем в каждом экземпляре Apache, на котором я запускаю приложение.

просто мои 2 цента...

Другие советы

Большая часть этого уже рассмотрена, но никто еще не упомянул SEO.Google придает большое значение самому URL-адресу: если этот URL-адрес виджетов.com/browse.php?17, это не очень оптимизировано для SEO.Если ваш URL-адрес — widgets.com/products/buttons/, это окажет положительное влияние на рейтинг вашей страницы для кнопок.

Хранение кода приложения в дереве документов веб-сервера является проблемой безопасности.

  • неправильная конфигурация может случайно раскрыть исходный код посетителям
  • файлы, внедренные через уязвимость безопасности, немедленно исполняются HTTP-запросами.
  • файлы резервных копий (созданные, например,текстовыми редакторами) может раскрыть код или быть исполняемым в случае неправильной конфигурации.
  • старые файлы, которые администратор не смог удалить, могут обнаружить непредусмотренную функциональность
  • запросы к файлам библиотеки должны быть явно отклонены
  • URL-адреса раскрывают детали реализации (какой язык/фреймворк использовался)

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

URL-адреса Django также легко настраиваются.С помощью PHP-фреймворков, таких как Code Igniter (я не уверен насчет Rails), вы вынуждены использовать структуру URL-адреса /class/method/extra/.Хотя это может быть хорошо для небольших проектов и приложений, как только вы попытаетесь сделать его более крупным/динамичным, вы столкнетесь с проблемами и вам придется переписывать часть кода платформы, чтобы справиться с этим.

Кроме того, маршрутизаторы похожи на mod_rewrite, но гораздо более гибкий.Они не привязаны к регулярным выражениям и, следовательно, имеют больше возможностей для различных типов маршрутов.

Зависит от того, насколько велико ваше приложение.У нас довольно большое приложение (более 50 моделей), и оно не вызывает у нас никаких проблем.Когда это произойдет, тогда мы побеспокоимся об этом.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top