Can I route to /api/cars.json and /api/cars/123.json within one endpoint file?

[205g0]

Pretty much the title. AFAIK, I have to create two files to catch aforementioned routes:

1. index.json in cars/
2. [id].json in cars/

Is there another way where I can put all in one file (where I would distinguish request based on given params)?

[ignatiusmb]

Yes, using rest parameters (https://kit.svelte.dev/docs#routing-advanced-rest-parameters), you can check if it ends with cars.json (or regex if you prefer) and handle the request accordingly.

[205g0]

wait, i was maybe too fast and wrote BS

this could work because the other folders in / might have higher precedence because of a better match. let me test this a bit...

[205g0]

but then again what if I have two [...rest].ts files/routes in /? which one would then take precedence?

[ignatiusmb]

It's ok, take your time. Yes, you would need to put the rest file in the same level as /cars to capture cars.json, but you don't need to rewrite the entire router there, instead try using the fallthrough routes feature to capture the more specific routes.

Another option is to keep the cars/index.json and cars/[id].json routes, and have a utility function you can call from both files.

[205g0]

instead try using the fallthrough routes feature to capture the more specific routes.

but how if you have two, e.g. [...cars].ts and [...users].ts in /?

(I just tested those, it doesn't work)

Another option is to keep the cars/index.json and cars/[id].json routes, and have a utility function you can call from both files.

i think, this is actually the only option which scales

re the utility function: in most cases you won't even need them because resolving one or many entities typically are different functions/orm/db calls at the end of the day

[ignatiusmb]

It doesn't make sense to have two rest parameters in the same level, and there shouldn't be any dynamic routes after the rest parameters.

resolving one or many entities typically are different functions/orm/db calls

Yes, that's the ideal design of an API.