Системный сдвиг

Забытое искусство конструирования 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: Ради чего мы всё это делаем и как измерить эффект? И кто всё это сведет воедино? Понятно, это западная статья, у них нет системных аналитиков, но мы-то знаем...