All language subtitles for 010 Exploring Different Ways Of Structuring API Route Files_Downloadly.ir_en

Now we know about API routes,

including dynamic API routes.

Now it is worth a note that

there are some alternatives to how we name

and structure our files inside of the API folder.

And those alternatives are equivalent

to the different approaches we can use

for regular pages.

For example, you can also have catch-all dynamic API routes

by adding free dots in front of any placeholder name

of your choice.

This will then not just handle requests to /API/some value,

but also to more segments you might have.

Equivalent to what you learned about regular pages

and catch-all pages.

Now we don't need a catch-all dynamic API route here

but it is worth knowing about it.

It's all important to understand

how Next.js prioritizes these different files.

If we send the request to /API/feedback,

it's decode into feedback.js file, it will be executed.

Now that is not necessarily obvious

because we have this dynamic API route.

So it could also be possible that requests to /API/feedback

are consumed by this file because feedback is simply treated

as a concrete value for this feedback ID placeholder.

But Next.js is smart just as it is for regular pages.

And if there is a more specific page for a given path value,

so since we have a feedback.js file in this case

it will use that more specific file

which makes more sense for this kind of path

than the more generic dynamic file.

/API some value on the other hand would trigger

the code in the dynamic API route.

So that's just worth knowing.

It automatically works correctly here

but it is important to be aware of the fact

that Next.js will do this prioritization for you.

Now, another important thing to know

is that you have some flexibility

regarding how you structure your files.

You can add a feedback.js file in the API folder

to support requests to /API/feedback.

Alternatively, just as with the regular pages,

you could also add a feedback sub folder in the API folder

and then move to file in there

and rename it to index.js.

And here vscode is asking me

whether it should automatically update all imports

that pointed at this file,

and I will say, yes.

If you don't get the prompt or you chose, no,

you should manually update those import puffs.

So that is the alternative.

A file named index.js in the feedback folder

in the API folder is the equivalent

to having a feedback.js file inside of the API folder,

just as it works for regular pages.

We can also move our feedback ID js file in there.

But if we do that,

that of course also changes the way our API works.

Previously, since feedback ID,

this dynamic API route was directly in the API folder

previously /API some value

triggered the code in this feedback ID file.

Now, since we're in a feedback sub folder,

it's actually /API/feedback/some value

that triggers the code in here.

Now that is actually a path that makes more sense to me.

It's more descriptive,

it's clearer that some requests sent

to /API/feedback/some value

should fetch more details for a single feedback

than if we have just /API/F1.

That doesn't tell us that it's about fetching feedback data

if we just look at this kind of path.

And hence it will keep this structure

of having these square bracket feedback ID file

inside of the feedback folder inside of the API folder.

However, that means that in the index.js file

in the feedback folder, in the regular pages.

So in the feedback page component,

we also need to update this URL

and send our request to /API/feedback/some ID,

because I changed that structure in the API's folder.

And now it looks like I broke some imports as well.

Yes, here we should import from the index file.

And now that works again.

So if I now reload, that all works,

that works, looking good.

So that is how you can also structure your files

and folders in the API folder, in the pages folder.

It essentially works just as it does

for regular pages.