When I first started learning JavaScript, I didn’t really understand how websites actually get their data. I thought everything was just written into the page somewhere.
Then I built a small project where I generated a random Pokémon , and that was the first time I worked with an API.
This post explains what an API is, what a fetch() request does, and what actually happens when a website asks another server for data.
I’ll use my random Pokémon generator as the example, because it is simple enough to understand without needing a big project.
What is an API?
An API is a way for one program, website, or app to communicate with another system. In a web project, an API is often a server that gives you structured data when you request a specific URL.
You can think of it like a website made for code instead of people. A normal website gives you a page to read. An API gives your code data that it can use.
For example, PokéAPI has data about Pokémon, including names, images, types, abilities, stats, and more. My website does not store all of that information by itself. It asks PokéAPI for the data it needs.
What is a fetch request?
In JavaScript, fetch() is a built-in browser function that can send a request to another URL.
The official
MDN Fetch API documentation
explains that the Fetch API is used for fetching resources, including across the network.
That URL can point to a normal file, a JSON file, or an API endpoint.
When you use fetch(), your website is basically saying:
“Please send me the data from this address.”
The server then responds. If the request works, the response usually contains data. Many APIs send that data back as JSON, which is a common format for structured information.
JSON can look a bit like a JavaScript object. It stores information as names and values, which makes it easier for code to read. The MDN guide to JSON is a good place to learn more about how JSON is used in web development.
What happens when you click the button?
In my random Pokémon generator, there is a button. When you click it, the website runs a small piece of JavaScript.
First, the code creates a random number. That number is used as the Pokémon ID.
Then the code adds that number to a PokéAPI URL. For example, this URL asks for Pokémon number 25:
https://pokeapi.co/api/v2/pokemon/25
After that, JavaScript sends a fetch() request to that URL.
PokéAPI receives the request, looks up the Pokémon data, and sends a response back.
The website then reads the response, takes the Pokémon name and image, and displays them on the page.
The code example
This is the simplified version of the code:
let id = Math.floor(Math.random() * 1024) + 1;
let fetchid = "https://pokeapi.co/api/v2/pokemon/" + id;
fetch(fetchid)
.then(response => response.json())
.then(data => {
imgElement.src = data.sprites.front_default;
output.innerHTML = data.name;
});
The first line creates a random number between 1 and 1024. The second line builds the API URL by adding that number to the PokéAPI address.
Then fetch(fetchid) sends the request.
The
MDN documentation for window.fetch()
explains that fetch() starts the process of fetching a resource and returns a Promise.
After the response arrives, response.json() is used to read the response body and parse it as JSON.
The
MDN documentation for Response.json()
explains this part in more detail.
After that, the code uses data.sprites.front_default for the Pokémon image and data.name for the Pokémon name.
Those values are then placed into the page.
What does the API send back?
The API does not send back a finished webpage. It sends back data.
For PokéAPI, the response contains a lot of information about the Pokémon. The generator only needs a small part of that response, so it uses the name and one sprite image.
This is one of the main ideas behind APIs. You can request a larger data object, then choose the specific parts your website actually needs.
What are API keys?
PokéAPI is nice for learning because you can use many of its endpoints without creating an account or adding an API key. The PokéAPI documentation says that no authentication is required, which makes it easy to test directly in the browser.
Many other APIs work differently. They require an API key, which is usually a long text token connected to your account or project. The API key tells the service who is making the request.
API keys are often used for access control, request limits, analytics, or billing. For example, paid APIs may count how many requests your key makes and charge your account based on usage.
That is why you should be careful with API keys. If a key is private or connected to a paid service, you should not paste it into public frontend code, a public GitHub repository, or a blog post. Other people could copy it and make requests through your account.
The OWASP Web Security Testing Guide explains that sensitive information, including private API keys, can be exposed when it is hardcoded into client-side code.
For public frontend projects, you usually want to use APIs that are safe to call from the browser, or you route secret requests through your own backend so the private key is not exposed to visitors. The OWASP REST Security Cheat Sheet also explains why API keys should not be treated as the only protection for sensitive or high-value resources.
Why this matters
This is how many modern websites work. They do not always have every piece of data written directly into the HTML page. Instead, they can request data when they need it.
That is how websites can show dynamic content, search results, live updates, user information, product data, or information from another service. My Pokémon generator is a very small example, but the basic idea is the same.
Once I understood this, web development made a lot more sense. A website can be more than a static page. It can ask for data, process it, and show something new based on the result.
When live API requests are useful
For a small learning project, requesting data directly from an API is a good way to understand how web development works. You click a button, the website sends a request, and the page updates with new information.
This makes the connection between JavaScript, APIs, and dynamic websites much easier to understand. That is why I think this kind of project is useful for beginners.
But live API requests are not always the best solution for every project. If a game or tool sends a new request every time the user clicks, the number of requests can grow quickly. For larger projects, it can be better to prepare the data once and store it locally as a JSON file.
I used that improved approach later in my Pokémon Higher or Lower game. Instead of fetching new data during every round, the game uses preloaded JSON data for better performance and stability.
You can read more about that here:
How I optimized a Pokémon API game using JSON instead of live requests
Why I used Pokémon
I think this part matters. If you are learning programming, it helps when the project is fun.
Pokémon was an easy choice because it is familiar, visual, and has a public API with useful data. Instead of only printing random numbers or placeholder text, I could generate something recognizable with a name and image.
That made the project more interesting to build and easier to understand. It also gave me a better feeling for how real data can be used inside a small browser tool.
Related project pages
You can try the random Pokémon generator here:
Open the Random Pokémon Generator
I also built a Pokémon Higher or Lower game that uses Pokémon stats in a different way. Instead of generating one random Pokémon, it compares two Pokémon and asks which one has the higher total base stats.
You can also visit my projects page to find more small browser tools, games, and coding experiments.
Sources and useful links
These are the main sources and technical references related to this post.
PokéAPI Documentation
Used as the Pokémon data source for this project. The documentation also explains that no authentication is required.
MDN Web Docs: Fetch API
Useful for understanding the browser Fetch API and how websites fetch resources across the network.
MDN Web Docs: Window fetch method
Useful for understanding what fetch() does in JavaScript.
MDN Web Docs: Response json method
Useful for understanding how API responses can be parsed as JSON.
MDN Web Docs: Working with JSON
Useful for learning what JSON is and why it is commonly used for structured data on the web.
OWASP: Review Web Page Content for Information Leakage
Useful for understanding why private API keys and other sensitive information should not be exposed in client-side code.
OWASP REST Security Cheat Sheet
Useful for understanding REST API security basics and why API keys should not be treated as the only protection for sensitive resources.
Final thoughts
This was one of the first projects where I understood that websites are not just static pages. They can request data, process it, and show something new every time.
That is a small idea, but it opens the door to a lot of web development. Once you understand API requests, many things on the internet start to feel less mysterious.
Disclaimer
This is a fan-made learning project created for educational and entertainment purposes only.
Pokémon and all related names, characters, images, and trademarks are the property of Nintendo, Game Freak, and The Pokémon Company.
This project is not affiliated with, endorsed by, or associated with Nintendo, Game Freak, or The Pokémon Company.
No comments:
Post a Comment