Clients, Servers & JSON APIs

Start with a question your product needs answered

A product might need a joke, tomorrow's weather or a list of public artworks. Rather than storing every possible answer in app.js, it asks a service for current data. Your browser is the client; the program answering is the server. An API is the contract describing the requests that program accepts and the responses it returns.

The contract matters more than the metaphor. “Give me a joke” must become a specific URL, method and response shape. A server does not guess what you meant from a random path.

Separate the parts of an endpoint

Consider this fictional example—do not expect it to be a real service:

https://api.example.com/products/42?currency=AUD

https is the connection scheme; api.example.com is the hostname; /products/42 is the path; currency=AUD is a query parameter. Together they identify the request target. Documentation may call https://api.example.com the base URL and /products/:id the endpoint pattern. Replace the id placeholder with a real identifier; do not literally request the colon.

An endpoint is not necessarily a whole website page. It may send JSON for code to use rather than HTML for a person to browse. APIs can also return text, files or other formats; check the contract instead of assuming everything is JSON.

Read one real-style JSON response

Open https://official-joke-api.appspot.com/random_joke in your browser. It is a public practice endpoint; availability and output can change. A response may look like this illustrative object:

{
  "id": 42,
  "type": "general",
  "setup": "Why did the developer bring a notebook?",
  "punchline": "To keep track of their ideas."
}

This is one object, not a list. id is a number; type, setup and punchline are strings. The sentence your page needs is in setup and punchline, not a field called joke. In JavaScript, data.setup reads that first sentence. data[0].setup would be appropriate only if the response were an array with an object at its first index.

JSON punctuation is part of the format: braces group an object, keys use double quotes, a colon connects a key to its value, commas separate fields. The printed response is text; your fetch code parses it into a value before accessing properties.

Read documentation with a purpose

For a new API, record these answers before writing the request:

1. Which endpoint supplies the specific data my product needs?
2. Which HTTP method and parameters does it accept?
3. Does it require authentication or a key? Is the key explicitly safe for browser use?
4. What does one successful response look like—object, array or a nested collection?
5. What are the error responses, usage limits and browser/CORS rules?

An address that opens in a browser tab is not proof JavaScript on another website can read it. The browser's CORS rules are covered later. Also check attribution and permitted use; publicly accessible data is not automatically yours to republish without conditions.

Turn data into a display plan

Suppose your dashboard has a heading and two lines for a joke. Write the mapping in your notes: setup → first line, punchline → second line, id → optional debugging identifier. Do not display every property merely because it exists. Pick useful labels and use plain text rendering for untrusted strings.

For an API returning an array, plan iteration: one object becomes one visible row/card. For a nested response such as {"items":[...]}, the list is in data.items, not data itself. Inspect the shape before reaching for map; “map is not a function” often means you tried to loop over an object or an error response.

Guided investigation

Open the practice URL, locate the two text fields and one numeric field, and copy only the field names into your notes. Refresh and notice the content can change while the structure remains the contract your app depends on. Predict the displayed text from one response before adding fetch code.

Then open your local site's DevTools Network panel and watch what requests occur on reload. Distinguish the HTML document, stylesheet, JavaScript file and any API fetch. Your upcoming dashboard should add a request to the selected endpoint; if it never appears, the function may not be called.

Troubleshooting and readiness

A missing route produces a response such as 404; an unavailable connection may produce no HTTP response at all. A successful response with unexpected fields requires checking the contract, not guessing property names. A service can limit requests: do not reload in a rapid loop to “fix” it.

Before the next lesson, identify client, server, endpoint, method and response body in one conversation. Explain how an actual JSON property becomes text on your page. You now have a concrete request to implement rather than a vague instruction to “use an API”.