React Introduction to APIs

In the last lesson you learned about React Hook Best Practices, so you’re comfortable with state and effects. Now let’s meet APIs, which are how your React app asks a server for real, live data instead of the hardcoded lists you’ve used so far.

🤔 Why do we need APIs?

Here’s the pain. Your app runs in the browser, but the real data lives far away on a server, so the two need a way to talk.

• Your app can’t reach into a database directly. That would be unsafe and messy.
• The data changes all the time, like new posts or live prices, so you can’t just hardcode it.
• Many different apps, a website and a phone app, need the same data from the same place.
• You need a clear, agreed way to ask for data and get an answer back.

So an API is that agreed way. It’s the doorway the server opens so apps can ask for data and send data, using a set of rules both sides understand.

🐍 What is an API?

API stands for Application Programming Interface. That sounds heavy, so let’s make it plain.

• An API is a set of rules that lets one program ask another program for something.
• For web apps, it usually means: your app sends a request to a web address, and the server sends back data.
• You don’t see how the server works inside. You just know what to ask for and what you’ll get back.

Think of it like ordering food by phone. You don’t go into the kitchen, you just call, say what you want, and the food comes out. The phone line and the menu are the “interface”, so you only need to know how to order, not how the kitchen runs.

🔁 How a request and response work

Every API call is the same simple back-and-forth. Your app asks, the server answers. Two steps, every time.

• Your app sends a request to a web address, called an endpoint, like https://api.example.com/users.
• The server does its work, maybe looks something up in its database.
• The server sends back a response, usually some data plus a status code.
• Your app reads that data and shows it on the screen.

Here’s the flow as a picture.

So the whole job of API code in React is just this: send the request, wait for the response, then put the data into state so it shows up.

📦 The data comes back as JSON

When the server answers, it needs a format both sides understand. On the web that format is almost always JSON.

• JSON stands for JavaScript Object Notation. It’s a simple text format for data.
• It looks almost exactly like a JavaScript object, with keys and values.
• It’s easy for your code to turn into a real JavaScript object you can use.

Here’s what a JSON response with a couple of users might look like.

[
  { "id": 1, "name": "Alex", "email": "alex@example.com" },
  { "id": 2, "name": "Riya", "email": "riya@example.com" }
]

Read what’s there.

• It’s an array of two objects, one per user.
• Each object has the same keys: id, name, and email.
• Once your app receives this, you can put it in state and map over it, exactly like the arrays you rendered before.

So JSON is the bridge. The server speaks it, your JavaScript understands it, and you turn it into a list on the screen.

🌍 What you can do with an API

APIs aren’t only for reading data. There’s a small set of common actions, and each has a name you’ll see everywhere.

GET    - read data        (get the list of users)
POST   - create data      (add a new user)
PUT    - update data      (change a user)
DELETE - remove data      (delete a user)

So the four words map to the four things you do with data.

• GET is by far the most common, and it’s where you’ll start: just reading data to show it.
• POST sends new data to the server, like submitting a form.
• PUT (or PATCH) changes something that already exists.
• DELETE removes something.

For now we’ll focus on GET, because showing live data is the first thing almost every app needs.

🔢 Status codes tell you what happened

Along with the data, the server sends a status code, a small number that says how the request went. You’ll meet a few again and again.

• 200 means OK, it worked, here’s your data.
• 404 means not found, that address has nothing.
• 500 means the server hit an error on its side.
• Codes in the 200 range are success, 400 range are your request’s problem, 500 range are the server’s problem.

So before trusting the data, good code checks the status. A 404 or 500 means there’s no real data to show, and you should display an error instead.

✅ Best Practices

A few ideas to keep in mind before you write your first request.

• Start with GET. Reading and showing data covers most of what apps need.
• Expect JSON. Plan to turn the response into a JavaScript object and store it in state.
• Always think about three states: loading, success, and error. A request takes time and can fail.
• Use public practice APIs while learning, like JSONPlaceholder, so you can focus on the React side.

🧩 What You’ve Learned

• ✅ An API is an agreed set of rules that lets your app ask a server for data and send data
• ✅ Every call is a request from your app and a response from the server
• ✅ An endpoint is the web address you send the request to
• ✅ Data comes back as JSON, a text format that maps neatly to JavaScript objects
• ✅ Common actions are GET (read), POST (create), PUT (update), and DELETE (remove)
• ✅ Status codes like 200, 404, and 500 tell you whether the request succeeded

🚀 What’s Next?

Now you understand what an API is and how the request-response flow works. Time to actually do it. Next you’ll write your first real request in React using the browser’s built-in fetch function.

React Fetch API