A cursor declaration in the route file gates the Pinia Colada adapter at compile time

The direction the types flow is what makes `defineRouteHandler()` worth reading. Yoshinori Ishii's argument in the post is that a server contract should do more than type the response, that it should constrain the handler, and that it should let the client switch on features which depend on that contract, so a pagination adapter can require a route that declares pagination ^[18].

Writing `pagination: { kind: 'cursor', item: Article }` in `server/api/articles.get.ts` gives the request validated `cursor` and `limit` query fields and pins the `200` body to `{ items: Article[], nextCursor?: string }` ^[5]. The handler's successful return has to match, so returning `{ nextCursor }` without `items` is a server-side type error ^[6]. The generated OpenAPI document carries the same fields, which is why another service or `curl` can call the route without NE ^[7]. On the client, `infiniteQueryOptions()` refuses an endpoint that does not declare the cursor contract, at compile time ^[8]. That is five distinct checks from one declaration ^[1], and the database query and cursor encoding are still your code ^[17].

Status narrowing is the other piece worth copying. A detail route declares `200` with an article and `404` with a message; checking `result.status` narrows `result.body`, so the 404 arrives as a value you handle rather than a thrown fetch error, while network failures still reject the request ^[10].

The limits are stated in the post itself, which is more than most pagination helpers bother with. Declared response types describe declared responses, and a proxy or other infrastructure can return something outside them ^[11]. The `{ items, nextCursor }` envelope is NE's convention, not an HTTP standard ^[12]. The contract checks shape, not semantics, so it cannot prove your query returned the right next page ^[13].

The form path keeps the same rule. In the experimental Nuxt 5 prototype the server is an explicit POST route that declares a form action of `/users/new` and a redirect to `/users/{id}` ^[14]. One `UserInput` schema validates both `application/json` and `application/x-www-form-urlencoded` bodies, the second through `formOf()`, alongside a declared `201` response ^[15]. The page side takes `form.attrs`, `form.enhance`, `form.fields` and `form.issues` from `useEndpointForm()` ^[16].

For that DX to transfer you need to be on H3, to accept a schema per route, and to tolerate churn, because the upstream validated-routing design is still under discussion and NE both implements and extends it ^[4]. The comparison the post is answering is server or remote functions in Next.js, SolidStart, TanStack Start and SvelteKit ^[1], so the choice on the table is who owns the contract rather than whether the URL survives.

Right now the contract's portable surface is the OpenAPI document, readable without NE ^[7], while the only compile-time consumer shown is NE's own adapter ^[8]. RFC #1437 is where that asymmetry gets settled.