Группы маршрутов и версионирование

Посмотрите на канон, который мы собирали четырнадцать уроков. app.Get("/api/tasks", ...), app.Post("/api/tasks", ...), app.Get("/api/tasks/:id", ...) — префикс /api повторяется в каждой строке, и это ещё четыре маршрута; настоящий сервис несёт десятки. За префиксом прячется более серьёзная проблема: общие правила зоны. «Все пути /api отвечают JSON-ошибками», «все пути /api/v1 требуют ключ» — формулируются эти требования про ветку целиком, а выражать их пока нечем: в шестом и седьмом уроках мы вешали middleware на всё приложение через app.Use или на отдельный маршрут вторым аргументом. Промежуточного уровня — «ветка маршрутов с общим префиксом и общими слоями» — у нас не было. Fiber группы маршрутов закрывают ровно эту дыру.

В прошлой лекции осталась и вторая незашитая нить. Мы разобрали, что App.ErrorHandler ищет обработчики ошибок по префиксам смонтированных sub-приложений — но что такое «префикс» и как его правильно построить, объяснено не было. Сегодня это станет рабочим инструментом: вы соберёте дерево /api → /v1 и /v2 и увидите, как на каждую версию API повесить свой формат ошибок, не ломая единый конверт.

Центральный метод урока объявлен в app.go и умещается в одну сигнатуру: func (app *App) Group(prefix string, handlers ...any) Router. Три наблюдения уже из неё. Первое: метод принимает префикс — строку, которая приклеится ко всем маршрутам, зарегистрированным через возвращённое значение. Второе: handlers вариадический и any — на группу сразу можно повесить middleware, и мы разберём, во что они превращаются (спойлер: в Use-маршрут на префиксе). Третье: возвращается Router — интерфейс, а не конкретный тип; это та же самая дверь, через которую вы работаете с app, и на этом держится вся композиция: у группы можно вызвать Group ещё раз, а функции-регистраторы можно писать один раз для любого узла дерева.

Канон не меняется: инстанс на :8080, helmet, cors и logger из шестого урока, страница задач из тринадцатого, ErrorHandler конвертом {error, code} из четырнадцатого. Новое — только геометрия: маршруты уезжают с корня в ветки.

Откроем исходники Fiber v3.5.0, файл group.go. Тип Group объявлен там первым и умещается в восемь строк: type Group struct { app App; parentGroup Group; name string; Prefix string; hasAnyRoute bool }. Док-комментарий формулирует назначение одной фразой: Group represents a collection of routes that share middleware and a common path prefix — «набор маршрутов с общим middleware и общим префиксом пути». Разберём поля, потому что каждое из них — это строчка поведения, которую мы сегодня потрогаем руками.

Поле app App — указатель на приложение-владелец: группы не создают своего движка, все маршруты регистрируются в общем стеке того же самого приложения. Отсюда важный вывод, к которому мы вернёмся в блоке про ошибки: группа сама по себе не несёт ни конфига, ни ErrorHandler — это просто угол дерева маршрутов одного приложения. Поле parentGroup Group — ссылка на родительскую группу: оно заполняется только при вложенном создании (api.Group("/v1")) и используется в неймспейсе имён, о котором поговорим ближе к концу урока. Поле name string — имя группы для Name-механики. Prefix — единственное экспортируемое поле: строку префикса можно читать напрямую из своего кода, например для стартового лога «зарегистрирована ветка /api/v1». И hasAnyRoute bool — флаг «в группе уже есть хоть один маршрут»: по нему Name решает, именовать ли саму группу или последний маршрут.

Второй герой блока — интерфейс Router из router.go. Это один контракт на восемнадцать методов: десять HTTP-методов (Get, Head, Post, Put, Delete, Connect, Options, Trace, Patch, Query), плюс Use, Add для списка методов, All для всех методов сразу, Group для вложенных веток, Domain для маршрутов по имени хоста, RouteChain и Route для цепочных и замыкательных форм регистрации и Name для имён. И самое главное: и App, и Group этот интерфейс реализуют. Поэтому не существует отдельного «типа группы-роутера» с урезанной логикой — у группы ровно те же методы регистрации, что у приложения, просто каждый путь они склеивают со своим префиксом. В курсе gin мы видели другой рисунок: там RouterGroup и Engine — разные структуры, а движок встраивает группу с флагом root: true. В Fiber рисунок проще: два типа, один интерфейс, никакого наследования — композиция через префиксы.

Настоящая сила групп — вложенность. В group.go метод Group есть и у самой группы, и работает он так: prefix = getGroupPath(grp.Prefix, prefix) — префикс ребёнка склеивается с префиксом родителя уже в момент создания, — затем создаётся новая структура &Group{Prefix: prefix, app: grp.app, parentGroup: grp} с заполненной ссылкой на родителя. Вложенная группа знает своего предка, живёт в том же приложении и несёт итоговый, полностью склеенный префикс. Дерево собирается в три строки: api := app.Group("/api"), v1 := api.Group("/v1"), v2 := api.Group("/v2") — и с этого момента v1.Get("/tasks", ...) регистрирует /api/v1/tasks, а v2.Get("/tasks", ...) — /api/v2/tasks. Одинаковые относительные пути /tasks на разных ветках больше не конфликтуют: полный путь разный.

Функция склейки getGroupPath объявлена в helpers.go и состоит из трёх шагов, которые стоит выучить дословно. Шаг первый: if path == "" { return prefix } — пустой относительный путь возвращает префикс как есть, поэтому api.Group("") легален и даёт снова /api. Шаг второй: if path[0] != '/' { path = "/" + path } — забыли ведущий слэш? Ничего страшного, функция допишет его сама: api.Group("v1") даст тот же /api/v1. Шаг третий: return utils.TrimRight(prefix, '/') + path — у префикса родителя обрезаются хвостовые слэши, и относительный путь приклеивается конкатенацией. Из-за обрезки хвостовых слэшей app.Group("/api/") и app.Group("/api") эквивалентны, а двойной слэш в стыке не появится никогда: он либо срезан справа от префикса, либо не возникнет из-за авто-слэша слева от пути.

Но конкатенация — не path.Join, и это принципиальная разница с gin, который мы разбирали в его десятом уроке. gin склеивает basePath через joinPaths — это path.Join плюс сохранение хвостового слэша, — а path.Join чистит сегменты: съедает двойные слэши и разрешает «..», поднимая ветку выше (v1.Group("../admin") в gin реально даст /api/admin). Fiber v3 ничего не резолвит: что написано в относительном пути после первого символа, то и приклеилось — «//» внутри пути останется двойным слэшем, а «..» уедет в маршрут литерально. На практике это значит одно: пишите префиксы аккуратно, без хитростей, — функция склейки вас не спасёт, да и не должна.

И последнее: вложенные группы — дешёвые структуры из пяти полей, никакой платы за уровень нет. Смело заводите по группе на смысловую зону — /api, версии, админка, health-зоны — но помните правило хорошего вкуса: каждый уровень должен либо вешать свой middleware, либо иметь собственный смысл; вложенность ради отступов читаемость не улучшает.

Теперь главный практический вопрос: как повесить общий middleware на ветку. Ответ мы уже дали в quiz-е, но соберём его целиком. В Fiber у группы нет собственного списка слоёв, который «накладывается» на маршруты, — вместо этого middleware, переданные в Group, регистрируются как Use-маршрут на префиксе ветки в общем стеке приложения. Use-маршрут совпадает с запросом по началу пути (так работает префиксный матчинг, о котором говорит и док-комментарий метода Use в group.go), поэтому слой, повешенный на /api/v1, исполнится для любого пути этой ветки — и для /api/v1/tasks, и для /api/v1/tasks/42. Эквивалентность полная: api.Group("/v1", requireAPIKey("s3cret")) и api.Group("/v1") с последующим v1.Use(requireAPIKey("s3cret")) до маршрутов — одно и то же.

Это даёт три формы, которые вы будете использовать постоянно. Первая: middleware прямо в вызове — v1 := api.Group("/v1", requireAPIKey("s3cret"), rateLimit()) — удобно, когда ветка объявляется один раз и слои у неё фиксированы. Вторая: v1.Use(...) после создания — удобно, когда слои добавляются по мере роста ветки, но строго до регистрации маршрутов. Третья: Use с префиксом внутри группы — v1.Use("/admin", adminGuard()) — префикс снова склеит getGroupPath, и слой ляжет на /api/v1/admin/*: подветка под защитой внутри ветки.

Почему «до маршрутов» — не стилистика, а механика? Потому что стек приложения сканируется по порядку регистрации. В router.go цикл app.next помечен комментарием Loop over the route stack starting from previous index: запрос идёт по стеку от начала, Use-маршруты продолжают цепочку, endpoint-маршрут отвечает и закрывает её. Слой, зарегистрированный после маршрута, в этом проходе встречается позже самого маршрута — маршрут уже ответил, и до слоя дело не доходит. Это то же правило «первый выигрывает», которое мы фиксируем с третьего урока, только применённое к группам: общие middleware объявляйте в Group или Use-ом сразу после создания группы, до первого Get/Post.

И связка с каноном: requireAPIKey("s3cret") из седьмого урока — фабрика, возвращающая fiber.Handler. Тогда мы вешали её на отдельный маршрут: app.Get("/api/notes", requireAPIKey("s3cret"), listNotes). Теперь та же фабрика встаёт на целую ветку — и один вызов защищает все маршруты версии, включая те, что вы добавите завтра.

Зачем вообще версии? Потому что контракт API нельзя менять молча. У вас есть клиенты: фронтенд, мобильное приложение, интеграции партнёров — они парсят конкретный формат ответа. Вы переименовали поле, свернули список в объект, добавили обязательный заголовок — и все старые клиенты сломались разом. Версионирование api — это соглашение: изменения, ломающие совместимость, уезжают в новый префикс, а старый продолжает работать как есть. Обе версии живут на одном дереве одного приложения: v1 обслуживает старых клиентов до момента, когда вы официально их выключите, v2 принимает новых. Это резко дешевле, чем «большой переезд» с одним днем переключения.

Группы дают версионирование почти даром, и вот практический скелет. Корневая группа /api — место общих для всех поколений вещей: /api/health, /api/version, общие слои вроде лога и лимитера. Каждая версия — ветка: v1 := api.Group("/v1"), v2 := api.Group("/v2"). Внутри версии пути могут совпадать один в один — /tasks есть и там, и там, — потому что полные пути разные. Хендлеры версий независимы: v1 может отдавать плоский формат, v2 — конверт с data и meta. При этом бизнес-логика под хендлерами общая: функции хранилища задач не дублируются, дублируется только транспортный слой. Правило экономии: дублировать — транспорт, не домен.

Какими маршрутами живет версия? Теми же восемнадцатью методами Router-интерфейса, что и корень: Get, Post, Put, Delete, Patch и так далее — на группе доступны все, плюс Add для списка методов и All для всех сразу. Отдельно скажем про эволюцию внутри одной версии: добавлять новые поля в v1 можно — старые клиенты игнорируют неизвестное; удалять или переименовывать — нельзя, это и есть сигнал для v2. Когда время v1 подходит к концу, на ветку вешается один Use-слой, отвечающий заголовком Deprecation (RFC 8594) или кодом 410 Gone на всё дерево, — и один день v1 := api.Group("/v1") просто удаляется из кода. Ничего другого трогать не придётся: в этом и смысл, что граница версии — одна строка.

Про совместимость с каноном: ErrorHandler из четырнадцатого урока у нас один на приложение и уже умеет ветвиться по strings.HasPrefix(c.Path(), "/api"). Версии ничего в нём не ломают: /api/v1/... начинается с /api, значит API-ветка конверта обслужит обе версии. Но у версий есть и более сильный инструмент — собственные обработчики ошибок на ветку; это следующий блок.

Тизер из четырнадцатого урока мы обещали развить: «научившись группировать маршруты, вы получите обработчики ошибок на каждую версию API отдельно». Теперь у нас есть префиксы — где здесь ошибки? Разберём честно, в два уровня.

Уровень первый — тот, что у вас уже работает. Группы не несут собственного ErrorHandler: группа — угол дерева одного приложения, а конфиг, включая ErrorHandler, один на приложение. Значит, ошибки из всех веток стекают в единственный обработчик корня. И этого достаточно для большинства проектов: внутри ErrorHandler вы ветвитесь по пути — strings.HasPrefix(c.Path(), "/api/v2") даёт возможность отвечать версии v2 её собственным конвертом, остальному /api — общим, страницам — HTML. Это по-прежнему «единая точка», просто с более мелкими развилками. Рекомендуем начинать именно так: один обработчик, ветки по префиксам, один конверт.

Уровень второй — когда версии должны быть по-настоящему самостоятельными: свой ErrorHandler, свой конфиг, возможно свой набор middleware-пакетов. Для этого fiber предоставляет монтаж: отдельное приложение fiber.New() со своим Config можно пристроить на ветку — app.Use("/api/v2", v2App). В group.go у Use есть ветка case *App: subApp = arg ... return grp.mount(prefix, subApp) — и маршруты смонтированного приложения начинают обслуживать пути под префиксом. А теперь главное, что мы объяснили в прошлый раз лишь на словах: метод App.ErrorHandler в app.go перед вызовом своего конфига ищет ErrorHandler среди смонтированных sub-приложений по их префиксам — док-комментарий формулирует это дословно: It searches any mounted sub fibers by their prefixes and if it finds a match, it uses that error handler. Из совпавших побеждает самый специфичный — с бо́льшим числом слэшей в префиксе; не нашлось — работает конфиг корня.

Соберём обе половины в одну картину: ошибка из хендлера /api/v1/tasks — поиск по префиксам не находит смонтированных приложений на /api/v1, работает корневой ErrorHandler с конвертом {error, code}. Ошибка из хендлера, живущего внутри смонтированного v2App на /api/v2, — префикс совпал, и клиент получает формат ошибок именно версии v2, какой бы странный он ни был. Именно это мы и обещали: обработчики ошибок на каждую версию отдельно, при этом группы — инструмент префиксов, а mount — инструмент собственных конфигов; связывает их поиск по префиксам. И да, 404/405 внутри веток идут через те же обработчики: emitSkip, о котором мы говорили в четырнадцатом уроке, работает на всём дереве.

Мы уже пользовались фактом «у группы те же методы, что у приложения», но теперь зафиксируем его как инструмент. Интерфейс Router объявлен в router.go: Use(args ...any), десять HTTP-методов с подписью (path string, handler any, handlers ...any) Router, Add(methods []string, path string, ...), All(path string, ...), Group(prefix string, handlers ...any), Domain(host string), RouteChain(path string), Route(prefix string, fn func(router Router), name ...string) и Name(name string). И App, и Group удовлетворяют этому интерфейсу. Практическое следствие — паттерн, который вы будете применять всю карьеру: функции-регистраторы, принимающие fiber.Router. func registerV1(r fiber.Router) { r.Get("/tasks", listTasks); r.Post("/tasks", createTask) } — эта функция честно отработает и на v1, и на v2, и на корневом app: внутри неё не написано ничего про префикс, склейку делает вызывающий.

Пара методов интерфейса, которые стоит знать сверх изученного. Add — регистрация списка методов разом: r.Add([]string{fiber.MethodGet, fiber.MethodHead}, "/tasks", listTasks). All — хендлер на все методы конфига (config.RequestMethods): так делают заглушки и «поймать всё». Route — замыкательная форма: app.Route("/api", func(r fiber.Router) { r.Get("/health", ...) }) создаёт группу, вызывает вашу функцию с ней и возвращает её; у Route есть необязательное имя для Name-неймспейса, а fn == nil паникует с сообщением route handler 'fn' cannot be nil. RouteChain — цепочная регистрация одного пути с общим префиксом. Domain — маршруты, привязанные к имени хоста, — упомянем и пойдём мимо: это ниша мультиарендных сервисов.

Отдельно — про any в подписях (handler any, handlers ...any). Fiber принимает не только func(Ctx) error: toFiberHandler в adapter.go распознаёт и Express-style подписи, и http.HandlerFunc, и fasthttp-хендлеры. Цена гибкости — паника на неподдерживаемом типе, и её текст стоит знать: collectHandlers паникует сообщением вида group: invalid handler #1 (тип) — «group» в начале это как раз контекст-строка, которую Group передаёт при регистрации своих handlers. Если увидите такую панику — вы передали в Group/маршрут функцию не той сигнатуры, и искать нужно не глубину вложенности, а тип аргумента.

И терминологическая скобка, чтобы не путаться в статьях: «группа маршрутов», «группа роутов», «роутер-группа» — всё о группе; Router же в fiber — имя интерфейса, а не типа группы. У gin, как мы видели в его десятом уроке, вместо одного Router-интерфейса — два (IRoutes и IRouter), а RouterGroup — отдельная структура, которую встраивает Engine с флагом root: true. Fiber-версия лаконичнее: два типа, один контракт.

Последний метод Router-интерфейса, который мы ещё не разбирали, — Name. Он двойственного поведения, и group.go описывает его в док-комментарии честно: Name Assign name to specific route or group itself. Если метод вызван до того, как в группу добавлен хоть один маршрут, — он именует саму группу: grp.name записывается в структуру, и срабатывает hook OnGroupNameHook. Если после — он именует последний зарегистрированный маршрут: вызов уходит в app.Name(name), а тот проставляет имя в стеке.

Интересна вложенность: при создании группы через api.Group("/v1") поле name наследуется конкатенацией — grp.name = grp.parentGroup.name + name. Без разделителя: если api.Name("api") и v1.Name(".v1"), итоговое имя группы — "api.v1"; точку (или другой разделитель) вы добавляете сами — механика просто клеит строки. Дальше имена маршрутов группы получают этот префикс автоматически: в app.go при именовании маршрута стоит route.Name = route.group.name + name — то есть v1.Get("/tasks", ...), v1.Name("list") даст маршруту имя "api.v1.list". Это и есть имя-неймспейс: имена маршрутов каждой ветки автоматически несут её идентификатор, и вы никогда не получите коллизию «list» из v1 против «list» из v2.

Зачем это на практике? Три сценария. Логи и метрики: имя маршрута — стабильный ключ, не зависящий от параметров пути; в ошибке или дашборде "api.v2.tasks.list" говорит больше, чем "/api/v2/tasks/:id". Отладка стека: при печати зарегистрированных маршрутов в стартовом логе имена делают дерево читаемым. Хуки: OnGroupNameHook и OnName — штатные точки, где можно собрать реестр веток приложения. Для чего Name НЕ нужен — так это для матчинга: маршрутизация идёт по путям и методам, имена — чистая метаинформация. Мы разобрали механизм базово, без URL-генерации; этого достаточно, чтобы читать чужой код и вести собственный реестр маршрутов.

Если вы прошли десятый урок курса gin — «Группы маршрутов», сегодняшняя тема покажется знакомой на девяносто процентов — и именно оставшиеся десять стоит проговорить, потому что это разные инженерные решения одинаковой задачи. Общее ядро совпадает дословно: группа = префикс + общие middleware, вложенность склеивает префиксы, версии API делаются ветками /v1 и /v2 на одном дереве, маршрут в группе записывается относительным путём, а «прописать полный путь внутри группы» — одна и та же ловушка в обоих фреймворках (двойной префикс регистрируется как обычный маршрут и молча ловит запросы).

Теперь различия. Первое — где живёт группа. В gin RouterGroup — отдельная структура с четырьмя полями (Handlers, basePath, engine, root), а движок Engine лишь встраивает корневую группу со basePath "/" и root: true — поэтому у движка «есть» методы GET и Group. В fiber группа Group — самостоятельный тип с указателем app на владельца, и *App реализует Router-интерфейс напрямую, без встраивания: наследования нет, есть два типа с общим контрактом. Второе — момент вычисления префикса. gin считает basePath сразу при создании (calculateAbsolutePath через joinPaths) и хранит приватно, выдавая наружу методом BasePath(); fiber тоже склеивает префикс вложенной группы при создании (getGroupPath), но хранит его в экспортируемом поле Prefix — читать можно прямо, метода не нужно.

Третье различие — философия склейки. gin склеивает через joinPaths, то есть path.Join: он чистит двойные слэши и разрешает «..», поэтому в gin v1.Group("../admin") поднимает ветку выше. fiber v3 в getGroupPath делает обрезку хвостовых слэшей префикса и конкатенацию — никаких чисток и резолвинга: что в относительном пути, то и в маршруте. Мы сознательно не рекомендуем «..» в обоих фреймворках, но в gin это работающая экзотика, а в fiber — дорога к сломанному пути. Четвёртое — механика общих middleware: gin в момент регистрации маршрута делает combineHandlers — снимок звеньев группы прямо в список хендлеров маршрута; fiber регистрирует слои группы отдельными Use-маршрутами в общем стеке. Эффект для аккуратного кода одинаков (слой на ветке работает для её маршрутов), а вот правило «поздний Use не действует задним числом» верно для обоих: и снимок gin, и порядок стека fiber фиксируются к моменту регистрации.

Пятое — интерфейсы: в gin два (IRoutes для регистрации, IRouter добавляет Group), в fiber — один Router на восемнадцать методов. Вывод практический не в пользу «кто лучше», а в пользу навыка: паттерн один — дерево префиксов с общими слоями, — и, освоив его в одном фреймворке, вы переносите его в другой за полчаса, сверяя только механику склейки.

Первая ловушка — двойной префикс. Симптом: запросы на /api/v1/api/v1/tasks отвечают 200, а на /api/v1/tasks — 404. Причина: внутри группы v1 написан полный путь v1.Get("/api/v1/tasks", ...) — getGroupPath честно приклеил префикс к уже полному пути, и маршрут зарегистрировался на удвоенном адресе; fiber не ругается, потому что формально это легальный маршрут. Лечение: в группах — только относительные пути; если хочется страховки, простой тест «GET по ожидаемому адресу» ловит это мгновенно. Заметьте: та же ловушка и в gin, где мы её уже разбирали, — проблема не фреймворка, а привычки.

Вторая — поздний Use. Симптом: страж на ветке пропускает все запросы. Причина: v1.Use(requireAPIKey(...)) вызван после регистрации маршрутов, а стек сканируется по порядку — endpoint-маршрут отвечает раньше, чем проход дойдёт до слоя. Лечение: общие слои — в аргументах Group или Use-ом сразу после создания группы, до первого маршрута.

Третья — слэш-фобия. Симптом: споры в ревью о хвостовых слэшах и ведущих слэшах. Причина незнания механики: getGroupPath срезает хвостовые слэши префикса и дописывает ведущий слэш пути, поэтому api.Group("/api/") и api.Group("v1") безопасны; а вот «//» внутри относительного пути сохранится — конкатенация сегменты не чистит. Лечение: не пишите хвостовые слэши в префиксах и никогда не пишите «..» в относительных путях — fiber, в отличие от gin с его path.Join, «..» не резолвит.

Четвёртая — паника при старте с текстом group: invalid handler #N. Причина: в Group передан аргумент, который toFiberHandler не распознал — чаще всего функция с неправильной сигнатурой (не func(Ctx) error) или случайное значение; collectHandlers паникует с индексом и типом. Лечение: читать тип из сообщения паники и чинить сигнатуру; «group» в сообщении — контекст регистрации именно групповых handlers.

Пятая — ожидание собственного ErrorHandler у группы. Симптом: попытка v1.Config{ErrorHandler: ...} не компилируется или ожидание «группа несёт свои слои, значит и обработчик» ломает план. Причина: у Group пять полей, конфига там нет — обработчики ошибок привязаны к приложениям и ищутся по префиксам смонтированных sub-app. Лечение: ветвление по пути в едином ErrorHandler либо монтирование отдельного fiber.New() на версию — оба способа мы разобрали выше.

Соберите канон целиком: инстанс на :8080, helmet, cors и logger из шестого урока, ErrorHandler с конвертом {error, code} и веткой для страниц из четырнадцатого, фабрика requireAPIKey("s3cret") из седьмого — и новое дерево: api := app.Group("/api"), v1 := api.Group("/v1", requireAPIKey("s3cret")), v2 := api.Group("/v2") с маршрутами задач в обеих версиях, плюс смонтированный v2App со своим ErrorHandler, если дошли до соответствующего блока. Прогоните шесть сценариев.

Первый: curl -H "X-API-Key: s3cret" localhost:8080/api/v1/tasks — 200 и список задач: страж пропустил, маршрут ветки ответил. Второй: тот же curl без заголовка — 401 от стража ветки, и проверьте, что /api/v2/tasks при этом отвечает свободно: области действия слоёв видны на паре запросов лучше, чем в любом объяснении. Третий: curl localhost:8080/api/v3/tasks — 404 и конверт {"error":"Not Found","code":404} из корневого ErrorHandler: незарегистрированная версия — обычный случай ErrNotFound. Четвёртый: сломайте формат v1 — добавьте в хендлер return errors.New("симуляция сбоя") — и убедитесь, что ошибка из ветки v1 отформатирована корневым конвертом, а ошибка внутри v2App — конвертом версии: поиск по префиксам в действии. Пятый: перенесите v1.Use(requireAPIKey("s3cret")) после регистрации маршрутов и повторите второй сценарий — страж замолчит; верните порядок. Шестой: curl localhost:8080/api/health — путь без версии с корневой группы: общий для всех поколений клиент.

Пара слов о том, чего в уроке нет и почему. Песочница сайта сетевые сценарии не исполняет — runner-ов в уроках Fiber нет с первого урока, интерактивы здесь quiz, predict, fill, order и флешкарты; дерево групп собирайте локально в терминале. И монтирование sub-app мы разобрали ровно настолько, насколько оно нужно для версионирования ошибок: полное сравнение монтирования с группами — за рамками урока.

Материал держится на четырёх опорах: структура Group из group.go, склейка getGroupPath из helpers.go, Router-интерфейс с восемнадцатью методами и поиск ErrorHandler по префиксам из app.go. Полный план курса — на странице курса Fiber, а механику ErrorHandler, на которую легли версии, мы подробно разбирали в четырнадцатом уроке; фабрика requireAPIKey — в седьмом.

Дальше — шестнадцатый урок про WebSocket: постоянное двунаправленное соединение поверх того же приложения. Дерево маршрутов вам пригодится сразу: веб-сокетные ветки заводятся группами так же, как версии API, и живут под общими слоями.