URL схема сайта

В вебе принято считать что url схема сайта — адреса страниц — частью внешнего интерфейса. Эти ссылки размещают на чужих сайтах и в комментариях, сохраняют в закладки браузера, по ссылкам ориентируются поисковики и другие роботы. Если взять и изменить адреса страниц на сайте, то это приведет к печальным последствиям: проект потеряет часть аудитории, ухудшатся позиции в поисковой выдаче Google/Yandex. По этой причине придерживайся нескольких правил.

Изменение адресов должно быть обратно совместимым

Для этих целей в течение нескольких месяцев поддерживают старые urls перенаправляя оттуда пользователей на новые адреса. Для этого подходит ответ сервера HTTP 301 — Permanent Redirect.

На многих проектах основную часть контента создают пользователи размещая на сайте статьи и комментарии. Если есть возможность хранить их вечно вместе с их уникальными url — это стоит сделать.

Не удалять user-generated content без особой необходимости

Про API

URL адреса API и формат ответа сервера — это вещи еще более стабильные чем адреса обычных страниц сайта. Что из этого следует:

Изменения в API вносят ОСТОРОЖНО и постепенно

На первом шаге создают новые endpoints — urls, обработчики, документацию к ним. Старые endpoints объявляют deprecated и ждут пока весь остальной код — фронтенд, например — успеет мигрировать на новые endpoints.

Если API публичный и его много кто использует, то ситуация становится еще сложнее. Часто приходится кроме актуальной версии API поддерживать еще несколько старых, несовместимых с новой.

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

Про файлы статики

С файлами статики наблюдается иная ситуация. Чужие сайты, роботы и приложения не зависят от адреса вашей favicon. Они не сломаются, можно смело заменить иконку на пачку png картинок с разными разрешениями. И этим активно пользуются перемещая файлы статики — картинки, CSS и JS. Вот несколько типичных ситуаций:

  1. Всю статику переносим на отдельный поддомен и размещаем в CDN. Сайт будет грузиться быстрее, нагрузка на сервер упадет;
  2. К адресам всех файлов статики добавляем хэш принуждая браузер сбросить кеш на свой стороне и загрузить актуальную версию файла /static/image.png --> /static.73e5ga73/image.png;
  3. В разработческой версии подменяем адрес статики https://mysite.com/static --> http://localhost:8080/, перенаправляем запросы к автоматическому сборщику статики Gulp/Grunt/Webpack.

В Django этот механизм используется еще активнее. Например, есть ManifestStaticFilesStorage который добавляет хеши к названиям отдельных файлов /static/image.png --> /static/image.73e5ga73.png. Вся эта магия происходит под капотом Django и чтобы ей не мешать используй тег {% static %}.