`build-routes` (suppression)

Purpose

buildSuppressionRoutes aggregates the four /suppression/* plugin route entries in canonical order (list, check, create, delete). The plugin's onInit consumes the array verbatim, so the OpenAPI spec order is deterministic and tests can assert it as a contract. Keeping the aggregator in its own module (rather than collapsed into the routes.ts file) mirrors the layout used elsewhere in the @suaveplan/* plugin family — code-search "build-routes" always finds the canonical-order anchor.

Features

Returns 4 entries in the documented canonical order.
Pure — no I/O, no captured state, no configuration knobs.
Each entry is independently mountable on a bare Hono app for testing.

Usage: Basic

import { buildSuppressionRoutes } from "@suaveplan/api-plugin-campaigns";

for (const e of buildSuppressionRoutes()) {
    app[e.route.method as "get" | "post" | "delete"](e.route.path, (c) =>
        e.handler(c)
    );
}

Usage: Advanced

import {
    buildSuppressionRoutes,
    definePluginRoutes,
} from "@suaveplan/api-plugin-campaigns";

const entries = buildSuppressionRoutes().map((e) => ({
    ...e,
    route: { ...e.route, path: `/api${e.route.path}` },
}));
definePluginRoutes(entries, { app, registry, pluginName: "campaigns" });

API Reference

buildSuppressionRoutes(): readonly PluginRouteEntry[] — returns the 4 entries in canonical order.

Implementation Notes

The check endpoint sits at position 2 (between list and create) because cache-friendly GET reads precede writes in the canonical order — operator-facing OpenAPI consumers naturally scan the read surface first when assessing rate-limit and caching budgets. The delete endpoint is last so the OpenAPI consumer reading the spec top-down sees the destructive operation last and is prompted to consider authentication scope before mounting.

1.9 KiB Raw Blame History

build-routes (suppression)