Afrikaans
Akan
Albanian
Amharic
Arabic
Armenian
Azerbaijani
Basque
Belarusian
Bemba
Bengali
Bihari
Bosnian
Breton
Bulgarian
Cambodian
Catalan
Cebuano
Cherokee
Chichewa
Chinese (Simplified)
Chinese (Traditional)
Corsican
Croatian
Czech
Danish
Dutch
English
Esperanto
Estonian
Ewe
Faroese
Filipino
Finnish
French
Frisian
Ga
Galician
Georgian
German
Greek
Guarani
Gujarati
Haitian Creole
Hausa
Hawaiian
Hebrew
Hindi
Hmong
Hungarian
Icelandic
Igbo
Indonesian
Interlingua
Irish
Italian
Japanese
Javanese
Kannada
Kazakh
Kinyarwanda
Kirundi
Kongo
Korean
Krio (Sierra Leone)
Kurdish
Kurdish (Soranî)
Kyrgyz
Laothian
Latin
Latvian
Lingala
Lithuanian
Lozi
Luganda
Luo
Luxembourgish
Macedonian
Malagasy
Malay
Malayalam
Maltese
Maori
Marathi
Mauritian Creole
Moldavian
Mongolian
Myanmar (Burmese)
Montenegrin
Nepali
Nigerian Pidgin
Northern Sotho
Norwegian
Norwegian (Nynorsk)
Occitan
Oriya
Oromo
Pashto
Polish
Portuguese (Brazil)
Portuguese (Portugal)
Punjabi
Quechua
Romanian
Romansh
Runyakitara
Russian
Samoan
Scots Gaelic
Serbian
Serbo-Croatian
Sesotho
Setswana
Seychellois Creole
Shona
Sindhi
Sinhalese
Slovak
Slovenian
Somali
Spanish
Spanish (Latin American)
Sundanese
Swahili
Swedish
Tajik
Tamil
Tatar
Telugu
Thai
Tigrinya
Tonga
Tshiluba
Tumbuka
Turkish
Turkmen
Twi
Uighur
Ukrainian
Urdu
Uzbek
Vietnamese
Welsh
Wolof
Xhosa
Yiddish
Yoruba
Zulu
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.
Can't find what you're looking for?
Get subtitles in any language from opensubtitles.com, and translate them here.