Topic 11

GET in the Address Bar

Hands-on

Two chapters of reading; now the sending starts — and your first API call needs no new tools at all. The web browser you have used your whole life is already an API client. It builds requests, sends them, and displays what comes back; it has just been doing all of that at doors built for people. This page points it at a door built for programs.

Type this into the address bar and press Enter: https://api.tandem.example/v1/stations/st_014. What appears is not a page. It is the station object for Old Market — raw JSON, in the window where websites usually go. You just made an API call, and the fear this book promised to dissolve took its first real dent.

What the browser did with your address
URL typedand Enter pressed
GET sentwith default headers
JSON displayedthe answer, undecorated

What the Browser Actually Did

Everything from Chapter 2, in order. It read your URL — scheme, host, path. It built a GET request, exactly the shape you saw on the request page, filling in sensible default headers. It sent the request, received the response, checked the verdict, and displayed the body. Those are the same steps every client in this book performs — the browser simply performs them without asking you anything.

The response that came back said Content-Type: application/json — data, not decoration. And that is why the result looks unstyled: no HTML arrived, because none was asked for and none was offered. As of 2026, Firefox displays JSON in a built-in viewer — colors, indentation, collapsible sections — while Chrome and Safari show it as plain text, one long line and all. Either way the answer is the same characters; the decoration, where it exists, is the browser being helpful.

Read What You Got

Look at what is on your screen: id, name, capacity, free_bikes — the same luggage tag of facts from Chapter 2's response page, now fetched by you personally. Try a small variation: change the path to /v1/stations and you get the list — fifty stations' worth, which looks like a wall and is not. Chapter 4 is entirely about reading walls like that comfortably; this page only needs you to see that the wall is the correct, healthy answer.

Where the Address Bar Stops

Honesty about the tool's limits, because they arrive quickly. The address bar can only send GET. It cannot choose headers — so no key, which locks it out of Chapter 5 onward. It cannot send a body — so no POST, no creating anything. It is a viewing slit, not a counter: good for a quick peek at a public endpoint, and a legitimate check that working professionals use daily, but real business needs the next two pages. Think of it as the staff entrance with a visitor badge: you can walk in and read the notice board; you cannot hand in forms.

Common Confusions
  • "This wall of text means something is broken." That wall is the answer — healthy, complete, exactly what the server promised. Unstyled is what data looks like; Chapter 4 makes it comfortable.
  • "The browser only opens websites." The browser speaks HTTP. Websites are just its most familiar conversation partner — point it at an API and it converses just as happily.
  • "If the browser can do it, I will not need curl." The address bar sends GETs with default headers, and nothing else. The first time you need a key or a POST — Chapter 5 and two pages from now — it is out of the game.
  • "The colors and collapsible arrows are part of the response." If your browser shows them, that is the browser prettifying JSON for you — and if it shows a plain wall of text instead, nothing is wrong. The response is plain text; any decoration lives entirely on your side.
Why It Matters
  • Zero-install first contact: one minute into the chapter, you have personally called a real API and read its answer. Everything after this is refinement, not initiation.
  • "Paste the endpoint into the browser" remains a genuine professional reflex — the fastest sanity check on any public GET endpoint, used daily by people who own far fancier tools.

Knowledge Check

Why does the API's answer look unstyled in the browser?

  • Because the page failed to finish loading completely before it was displayed
  • Because the response is data labelled as JSON, and no HTML arrived to style
  • Because ordinary browsers are not able to display responses that come from APIs
  • Because the server refused to send the styled version to a stranger

Which of these can the address bar NOT do?

  • Send a GET request to a public API endpoint and display the answer it returns
  • Fetch a list as large as fifty stations' worth of data in a single request
  • Attach a header of your choosing, such as the key Chapter 5 introduces
  • Ask for a different station by editing the path in the address

What did the browser do between your Enter and the JSON appearing?

  • Built a GET request from the URL, sent it, and displayed the response body
  • Searched the web for the address and displayed the closest matching result
  • Downloaded the API's database and selected the station you asked about
  • Opened a stored offline copy of the Tandem website from its cache

You got correct