Think of a restaurant. You, the customer, want to order food, but you don't go into the kitchen to cook it yourself. The kitchen is a complex system with its own rules and processes. Instead, you interact with a waiter.

You tell the waiter what you want (a request). The waiter takes your request to the kitchen, which prepares your meal. Then, the waiter brings the food back to you (a response). The waiter is the intermediary, allowing you to get what you need from the kitchen without knowing how it works.

When you use an app on your phone to check the weather, that app is talking to a weather service's system through an API. Your app (the customer) sends a request for the forecast in your city. The weather service's system (the kitchen) finds the data and sends it back through the API. The app then displays that data to you in a clean, readable format.

This interaction always involves two parties: a client and a server.

• The Client is the application that makes the request. In our restaurant analogy, you are the client. In the weather app example, the app on your phone is the client. Your web browser is also a client when it requests a webpage.

• The Server is the application or system that holds the data or functionality and sends the response. The restaurant's kitchen is the server. The powerful computers holding all the weather data are the server.

This whole process of asking and receiving is called the request-response cycle. It's the fundamental pattern of communication on the web. A client packages a request with all the necessary information and sends it to a server. The server processes the request, finds the requested information or performs an action, and then packages a response to send back to the client.

To make a specific request, the client needs a specific address. This is where URLs come in.

A URL (Uniform Resource Locator) is the address used to find a resource on the internet. When you type an address into your browser, you're using a URL. APIs use URLs to define endpoints, which are the specific locations where requests can be sent.

Let's break down a sample URL: https://api.example.com/v1/weather?city=London

Every part of the URL gives the server important information about what the client is asking for. By changing the path or the query, you can ask for different things from the same API. For example, changing the query to ?city=Tokyo would fetch the weather for Tokyo instead.

Now you know the core concepts behind how applications communicate. Let's test your knowledge.

Understanding these fundamentals is the first step to working with any API.