Забытое искусство конструирования URL. Нашел классную статью про URL'ы: https://alfy.blog/2025/10/31/your-url-is-your-state.html

Главная идея: URL'ы — это состояния. Похоже на REST, да? Всё крутится вокруг состояний приложения, и каждый URL представляет некоторое состояние. Это относится и к API, а к web-приложениям — в особенности.

При этом URL — это такая пограничная тема между бэкендом и фронтендом. Кто за них отвечает? Кто их проектирует? Или как они вообще появляются? Иногда — аналитик (для API). Для приложения — непонятно, кто.

Современные фронтендеры часто вообще не понимают, о чем речь. Типичное проявление: вы устанавливаете фильтр на таблицу или список, потом переходите к конкретному экземпляру, потом возвращаетесь обратно — и все фильтры сброшены. Ну конечно, а где их сохранить? В cookie? В localStorage/sessionStorage? В внутрибраузерной indexedDB? Так много вариантов и очень сложно в реализации. Вот бы был простой способ сохранить это состояние без всяких баз.

И этот способ есть — это URL. Хорошо спроектированные ссылки бесплатно дают сразу несколько возможностей:
— шеринг: я отправляю ссылку, и получатель видит ровно то же, что я вижу;
— закладки: я сохраняю закладку = сохраняю конкретный момент времени;
— история: кнопка "назад" в браузере/смартфоне просто работает;
— глубокие ссылки и вложенные состояния: можно попасть напрямую в какое-то специальное состояние приложения.

Основной элемент URL для этого — query parameters, параметры запроса(строка после ?). И такой недооцененный элемент URL, как фрагмент (строка после #).

Эти части URL можно использовать очень творчески, например, в GitHub добавление фрагмента #L108-L136 будет означать "показать исходник, выделив в нем строки 108-136".

А вот как записываются в URL координаты в Google Maps: @22.443842,-74.220744,19z

Состояние чего мы можем хранить в URL? Какие данные о состоянии приложения?
— Поисковый запрос
— Фильтры
— Пагинация
— Сортировка
— Модель просмотра (таблица / список / карточки)
— Период дат/времени
— Диапазон строк или ещё чего-то счетного (в отличие от пагинации, здесь имеется в виду подсвечивание на странице)
— Координаты или область просмотра для больших графических представлений (карты, доски)
— Выбранные опции, выделенные элементы, активные вкладки, раскрытые/закрытые элементы в древовидных структурах
— Параметры конфигурации интерфейса, например — язык или тема (темная/светлая)
— Фича-флаги, варианты A/B-тестов

Какие типовые подходы есть к кодированию информации в query:
Значения параметров через & : ?debug=true&analytics=false или даже без значения: ?mobile (самого наличия флага уже достаточно)
Множественные значения:
?languages=javascript+typescript+python или
?languages=javascript,typescript,python
Массивы: ?ids[0]=42&ids[1]=73 (php поддерживает парсинг такого автоматически)
Структурированные данные:
?filters=status:active,owner:me,priority:high или даже JSON в форме base-64:
?config=eyJyaWNrIjoicm9sbCJ9== (но это уже не очень хорошо, URL перестал быть человекочитаемым)

Это же можно использовать и для управления кэшированием и отслеживания по логам.

В общем, проблема проектирования URL получается на стыке:
Product/UX: Как будет понятно и удобно пользователям?
Frontend team: Как удобнее писать клиентов?
Backend team: Как наиболее эффективно парсить и распознавать URL'ы?
DevOps: Как настроить кэширование и маршрутизацию?
SEO/Marketing/Product: Ради чего мы всё это делаем и как измерить эффект?

И кто всё это сведет воедино? Понятно, это западная статья, у них нет системных аналитиков, но мы-то знаем...