Unexpected routing behavior for api sub-routes

[jahands]

A behavior I found unexpected is the way API routes match splats without using the normal flat routes syntax for splats.

To match the following routes:

/api
/api/foo
/api/foo/bar

I'd expect to create routes/api.$.ts based on the docs for splat routes, but instead I must create routes/api.ts

Why don't API routes use the normal routing syntax?

[zebp]

Trying to understand the issue since api.$.ts will match those paths. Is the issue that api.ts does match those routes which isn't consistent for component routes?

[jahands]

api.$.ts will match those paths

It's broken though - if I use api.$.ts, my Hono app never receives the rest of the path. Example:

• Code: api.$.ts
• URL: https://1bdaf5e3-my-orange-project.jhands.workers.dev/api/foo
• Hono is receiving the path /

But if I switch to api.ts:

• Code: api.ts
• URL: https://15d0c50d-my-orange-project.jhands.workers.dev/api/foo
• Hono is receiving the path /foo

Is the issue that api.ts does match those routes which isn't consistent for component routes?

Yes that's what I'm finding weird - I'd expect routing to be consistent. This behavior also makes #11 difficult to implement (if we end up wanting to do that)

[zebp]

Been thinking about the best solution to this for a bit. I think that the ideal solution would be that without a $ suffix no extra path segments are matched and that api routes use up to the first dynamic path as the base path. So in api.$.ts, if I wanted to match /api/foo I'd write this:

const app = new Hono();

app.get("/foo", (c) => c.text("whatever"));

export default app;

@jahands does this seem like a sufficient solution in your opinion?

[jahands]

Yes I think that would make sense! So if I have api.ts, I would only match requests to /api correct?

I think this will help a lot because it’s confusing needing to know that a file happens to have dynamic matching because of a config somewhere while other routes require $ to be dynamic.