This check exists to ensure the API endpoints aren't exploited
on account of using the catch-all [...id] notation.

The catch-all/api/local/[...id] route is in place to enable support for dual
script variants in the request path.

We may be able to use the catch-all syntax for API routes, similar to what we've done within the pages/[service]/live and pages/[service]/send folders. The entry point into those pages is [[...variant]].page.tsx which catches the optional variant parameter.

Would something like /api/local/[service]/[pageType]/[id]/[[...variant]] work? Thats the pattern for our current Next.js pages. That could change in the future though once we migrate other page types over than have the variant within the URL params, rather than at the end, but may be something to tackle at that time.

That would mean that you would need to work out where to point to the .json file in the API, since the folder structure for the JSON data would be different to the actual route requested. I think that may be ok though? Otherwise the local URL would need manually constructed as you have in constructedPageFetchUrl, so I guess either way there will be some manual pathing required.

Thank you for the feedback Aaron.
I had considered going the /api/local/[service]/[pageType]/[id]/[[...variant]]
way similar to your recommendation. I however sought to replicate the current dual script
routes for Live Pages such as the pages linked below hence logic seen in constructDataFilePath.

https://www.bbc.com/zhongwen/simp/live/world-47367050
https://www.bbc.com/zhongwen/trad/live/world-47367050

In keeping with the current route structure for Live Pages where the optional catch-all
supports passing the variant at the end, I'll change the API to accept the variant at the
end of the URL path.

Is there any chance that this could be renamed (and the fixtures moved) to live instead of livePage? Just for consistency / better dev-x because we can find things more easily..?

I think this is probably what Aaron is also discussing https://github.com/bbc/simorgh/pull/11753/files#r1700322809

Thanks for the feedback Karina.
Yes. This is feasible. I adopted the livePage directory name based
on what's currently on latest.
We can adopt the name, live, directory though and remove the need to infer it using
getFixtureLocation.
I'll proceed to make this change.