Подтвердить что ты не робот

Поддомен против подкаталога в веб-программировании

Существуют две основные стратегии обработки нескольких "приложений" в Интернете:

  • субдомены (например, wiki.example.org, blog.example.org, admin.example.org, api.example.org/v1)
  • (например, example.org/wiki, example.org/blog, example.org/admin, example.org/api/v1)

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

Изменить: CW, если есть правильный ответ, но он очень широк.

4b9b3361

ОТВЕТЫ

Ответ 1

Помимо того факта, что с точки зрения безопасности немного проще изолировать приложение внутри субдомена, я просто прокомментирую то, что, по моему мнению, является самым большим различием между ними.

Pro для поддоменов:

  • Вы можете изолировать конфигурацию (например, apache) для каждого домена.
  • Вам будет проще переносить части вашего приложения на другие машины. Подкаталоги не будут давать вам такую ​​гибкость.
  • Вместо того, чтобы использовать переменную $baseUri в каждом шаблоне html, вы можете просто предположить, что корень приложения всегда /.

Минусы:

  • Нам будет гораздо более неприятно быстро настраивать среднюю стадию разработки или временную разработку. Для каждого "приложения" вам понадобятся DNS-хосты файлы и конфигурация веб-сервера. С помощью подкаталогов вы можете удалить приложение в каталог и перейти!
  • Если у вас когда-либо было требование развернуть ваше приложение в другой системе, где использование/из-за какой-то нечетной политики не представляется возможным, может произойти некоторая переписывание.

Мой совет:

Удостоверьтесь, что вы всегда можете обойти оба, что даст вам лучшее из обоих миров. Каждая часть вашего приложения должна иметь настраиваемый базовый uri, который всегда соблюдается. До тех пор, пока вы убедитесь, что вы всегда можете идти в обоих направлениях, то кто заботится о том, что вы делаете? это просто URL-адрес, и он всегда может быть изменен.

Ответ 2

  • В терминах организации кода: различия ноль, так как вы можете сопоставить субдомены в любом каталоге.
  • С точки зрения безопасности браузера: возможен доступ JavaScript через субдомены, но есть препятствия (см. document.domain и супруги). Я ничего не знаю на стороне JavaScript, что совершенно невозможно при работе с разными поддоменами.

Мнение:

Я лично склоняюсь к каталогам и к поддоменам для публичных адресов. Широкая публика стала использоваться для веб-адресов, начинающихся с "www". и это создает ненужную путаницу, чтобы разбить этот шаблон. Вы заметите, что очень часто люди, получая поддомен для ввода в адресную строку, автоматически начинают вводить "www". и они будут удивлены, узнав, что адрес может быть без.

Для меня единственным хорошим способом использования субдоменов является использование внутренних целей для облегчения или подготовки к использованию разных серверов (например, static.example.com, images.example.com и т.д.).

Ответ 3

Лично я предпочитаю использовать субдомен для каждого приложения, а затем субдиры (независимо от того, являются ли они фактически подкаталогами или нет - предпочтительно они просто перенаправляются на /index.php на .htaccess) для обозначения различные состояния этого приложения. Например:

admin.blah.com/users/1234/bob,
admin.blah.com/pages/4321/title,
blog.blah.com/archives/2007/5678/title и др.

Субдомен сообщает вам, где вы находитесь, и подкаталоги сообщают вам, что вы делаете.

Ответ 4

  • Вы можете легко "делать" виртуальные серверы на субдоменах.
  • Вы можете выделить субдомены для разных файлов cookie.

Лучше всего было бы признать, что субдомены являются "основным" разделением в веб-пространстве, а подкаталоги - "второстепенными". Субдомены для, ну, разных областей; у вас могут быть разные люди, работающие с разными приложениями на разных поддоменах. Подкаталоги являются разделами одного (суб) домена, разделяющего, возможно, разные приложения одним и тем же пользователем.

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

Ответ 5

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

dev.example.com

и сделайте копию своего сайта, включая всю структуру каталогов. Запустите файл .htaccess, чтобы отказать в подключении от кого-либо, кроме вас и вашего IP-адреса клиента, и использовать его для внесения изменений до тех пор, пока обновления не будут готовы к нажатию в реальном времени.

Ответ 6

Это довольно большая тема, но есть некоторые мысли о поддоменах...

Pros

  • Можно использовать "чистую настройку маршрутизации", если вы используете MVC.

  • Очень четкое разделение между частями система и отсутствие пространства имен перекрытия.

против

  • С другой стороны, вероятность больше дублирования кода на backend, если вы не умны с библиотека/включает в себя каталоги и использование общая область.

С точки зрения SEO, нет  в эти дни большая разница  и даже такие инструменты, как Google  Google Analytics может быть проинструктировано использовать определенный домен регистрации.

Ответ 9

Я думаю, что тремя наиболее важными причинами использования sub.domains, в отличие от подкаталогов, являются безопасность, безопасность и безопасность. Суб/каталоги подвергают сеанс сервера хакерам.

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

domain.com/application1

domain.com/application2

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