Every frontend developer eventually opens the Network tab, watches a wall of requests scroll past, and realises the content on the page has to come from somewhere. Usually that somewhere is a REST API. You don't need to build one to use one well, but you do need to understand a handful of conventions. Once those click, working with an unfamiliar API stops being a guessing game and becomes a process of reading, testing and adjusting.
What REST actually means
REST is a set of conventions, not a piece of software you install. The core idea is simple: everything you work with is a resource, and each resource has its own URL. A collection of users lives at /users. One specific user lives at /users/42. Their orders live at /users/42/orders. The pattern repeats across almost every API you'll meet.
The other half of the idea is that the URL says what you're working with, and the HTTP method says what you want to do with it. That separation is why the same endpoint can return a user, update a user, or delete a user depending on the verb you send. It's also why you should be suspicious of any API that hides actions in URLs like /deleteUserNow.
The HTTP methods you'll use constantly
Four verbs cover the vast majority of frontend work:
- GET — fetch data. It should never change anything on the server. Because of that, it can be cached and bookmarked, and you can test it by pasting the URL straight into your browser's address bar.
- POST — create something new, or trigger an action. The data you send goes in the request body, not the URL.
- PUT and PATCH — update an existing resource. In theory PUT replaces the whole thing while PATCH changes only the fields you send. In practice, plenty of APIs use PUT for partial updates, so check the docs rather than assuming.
- DELETE — remove a resource. Often it returns nothing at all, which is perfectly normal.
When you send data, you'll usually be posting JSON. That means setting a Content-Type: application/json header and passing a JSON string as the body. If you forget the header, some servers will ignore your carefully built payload and hand you back a confusing error.
Status codes, decoded
Every response starts with a three-digit number that tells you roughly what happened. You don't need to memorise all of them, but you do need to group them correctly.
2xx — it worked
200 OK is the standard success. 201 Created usually follows a POST and often includes the new resource. 204 No Content means success with an empty body, common after a DELETE.
4xx — the request was the problem
400 Bad Request means the server couldn't understand what you sent. 401 Unauthorised means you're not authenticated — missing token, expired token, wrong header. 403 Forbidden means the server knows who you are and you still can't do this. 404 Not Found is either a wrong URL or a record that genuinely doesn't exist. 422 Unprocessable Entity typically means validation failed, and the body often lists exactly which field. 429 Too Many Requests means you've hit a rate limit and should slow down.
5xx — their side broke
500, 502 and 503 are server failures. There is nothing you can fix in your code, so show the user a sensible message and, if it's a 503, maybe retry once after a pause.
One practical warning: fetch() does not throw on a 404 or a 500. It only rejects on network failures. Check response.ok or the status code yourself before you try to parse anything.
JSON: read the shape before writing code
JSON is just objects, arrays, strings, numbers, booleans and null. The difficulty isn't the syntax, it's the shape of a specific API's response. Before you write a single line of component code, make a real request and look at the result.
Two habits pay off here. First, prefer optional chaining and sensible defaults when you reach into a response — user?.address?.city is far friendlier than a crash when a field is missing. Second, watch out for the difference between null and a key that isn't there at all. They often mean different things to the backend, and they will behave differently in your UI.
Your first request, step by step
A repeatable routine makes an unfamiliar API far less intimidating:
- Find the base URL and the endpoint you need in the documentation.
- If it's a GET, paste the full URL into your browser and inspect the raw response.
- Identify the exact fields you need, and note which ones can be missing.
- Write the request in code using fetch or a library such as Axios.
- Check the status before parsing the body.
- Log the parsed data once, then remove the log and render it.
A minimal call looks like this: const res = await fetch(url, { headers: { Accept: 'application/json' } }); followed by a check of res.ok and then await res.json(). Sending data means adding the method, the content type header and a stringified body. Authenticating usually means an Authorization: Bearer <token> header — keep tokens out of URLs, where they end up in logs and browser history.
If a request fails in the browser but works in Postman or curl, the culprit is often CORS. That's a browser security rule enforced by the server's headers, not a bug in your fetch call. You'll usually need to raise it with whoever owns the API.
Habits that save you time
- Treat every API as unreliable. Design empty, loading and error states before the happy path.
- Keep requests in one small module rather than scattering URLs across components. When the base URL changes, you'll change it once.
- Read the error body. A 400 or 422 often contains a message or field list you can show the user directly.
- Don't retry blindly. Retrying a failed POST can create duplicate records.
- Watch the Network tab while you build. It tells you more about an API than most documentation does.
Putting it into practice
Pick a small project this week: a weather lookup, a public list of books, anything with a documented endpoint you can call without an account. Build one page that fetches data, handles a loading state, handles a failure, and displays a few fields. Then add a form that posts something back.
That exercise covers most of what a frontend developer needs from REST in day-to-day work. From there, the reference material on MDN and the API's own docs will answer almost everything else — and the Network tab will tell you the truth when they don't.
Photo: Godfrey Atima / Pexels
