6. Chapter review

You've built the mental model for how modern apps talk to each other over the web. The rest of this chapter ties it together: how applications shifted from isolation to connection, what you can now do, and a short quiz to lock the concepts in.

Why everything is connected

Twenty years ago, applications were islands. Microsoft Word was a program on your computer. It didn't talk to anything else. Your saved documents lived only on your hard drive. If you wanted to work on a document from a different computer, you had to physically copy it using a USB drive or email it to yourself.

Today, you open Google Docs and your document is just there. On your phone, your laptop, your friend's computer. You can see who else is viewing it in real time. Comments appear instantly. Changes sync automatically. This isn't magic. It's APIs.

When you type in Google Docs, your browser sends your edits to Google's servers through an API. The servers save your changes and broadcast them to anyone else viewing the document. When your friend types something, their changes come back to you through the same API. You're not working on a file stored on your computer. You're working on data stored in Google's data centres, accessed through APIs.

The shift: from standalone to connected

This shift from isolated applications to connected services happened because of three realisations:

  • Data is more valuable than code. Your photos, documents, and messages matter more than the apps that display them. Users expect their data everywhere, on any device. The only way to deliver this is by storing data centrally and providing API access to it.
  • Specialisation works better than integration. Stripe processes payments better than you ever could, because that's all they do. Google Maps provides better directions than any navigation system you could build from scratch. Instead of building mediocre versions of everything, companies build APIs to excellent services and let others integrate them.
  • Users expect everything to work together. When you order food through DoorDash, you expect it to show your location (Google Maps API), charge your card (Stripe API), send you text updates (Twilio API), and display restaurant photos (cloud storage APIs). Users don't care how many different services are coordinating behind the scenes. They just expect it to work seamlessly.

This is why APIs became the foundation of modern software development. Many successful companies, including Uber, Airbnb, Spotify, and Netflix, grew by connecting different services through APIs rather than building everything themselves.

What you can do now

You can explain what an API is in plain language: an interface to a service running on a server that your application can communicate with over the internet. You recognise the request-response cycle and know it's universal across all web APIs. You can identify the four main HTTP methods (GET, POST, PUT, DELETE) and what each one does. You can read JSON data structures and break down any URL into its components. You can interpret status codes and know whether a 4xx means fix your request or a 5xx means wait for the service to recover.

This conceptual foundation is essential. Before writing a single line of code, you need to understand what you're building and why it matters. The rest of this book transforms this understanding into practical skill: the ability to connect external services to your own applications with confidence.

Chapter review quiz

Test your understanding of the fundamentals that power modern connected applications:

Select a question to reveal the answer:
What is an API and why do modern applications need them?

An API is a service running on a server that your application can communicate with by sending requests over the internet. Modern applications need APIs because they enable specialisation (using best-in-class services instead of building everything yourself), data accessibility across devices, and seamless integration between different services without building complex systems from scratch.

Explain the restaurant analogy for APIs. What does each component represent?

In the restaurant analogy:

  • The menu represents the API documentation, showing what operations are available
  • The waiter represents the API itself, taking your request to the kitchen and bringing back the response
  • The kitchen represents the backend servers where the actual work happens
  • You (the customer) represent the client application making requests

Just like you don't need to know how the kitchen works to order food, you don't need to understand a company's internal systems to use their API.

What are the three main reasons companies build APIs?

1. Platform effect. Reaching more users through third-party integrations. When developers build products using your API, they extend your platform in ways you couldn't imagine, making your service more valuable.

2. Revenue. APIs themselves become products that generate income. Companies charge for API access (per request, per message, per usage tier), monetising their infrastructure at scale.

3. Competitive advantage. The best services provide APIs to remain relevant and enable innovation. Without APIs, companies can't integrate with other tools, automate workflows, or scale to handle enterprise customers.

What's the difference between a Web API, a library, and a framework?

Web API: an interface to a remote service accessed over the internet. It requires network connectivity and you make HTTP requests to someone else's servers. Example: requests.get("https://api.example-weather.com/forecast").

Library: pre-written code you include in your program that runs locally. No network required. It's part of your application. Example: import pandas.

Framework: a structure that dictates how you build applications. You write code that fits into its architecture, and the framework calls your code. Example: building a Django website where you define views that Django invokes.

What does REST API mean and what makes an API RESTful?

REST (Representational State Transfer) is an architectural style for designing web APIs. A RESTful API follows these principles:

  • Resource-based URLs: each resource has a clear URL like /users/123 or /products/456
  • HTTP methods indicate actions: GET retrieves, POST creates, PUT updates, DELETE removes. The same URL does different things based on the method
  • Stateless communication: each request contains everything the server needs, with no memory of previous requests
  • Standard status codes: uses HTTP status codes consistently (200 for success, 404 for not found, etc.)
  • JSON responses: most return data in JSON format

The vast majority of public APIs are RESTful. Once you understand REST patterns, you can work with thousands of different APIs because many of them follow similar design principles.

What are the four most common HTTP methods and what does each one do?
  • GET: retrieve data without changing server state (usually the safest method to experiment with)
  • POST: create new data or resources
  • PUT: update existing data or resources
  • DELETE: remove data or resources

These methods are like verbs. They tell the API what action you want to perform on a resource.

What is JSON and why is it the preferred format for API communication?

JSON (JavaScript Object Notation) is a text format for representing structured data. It's preferred because:

  • It's human-readable: you can understand it by looking at it
  • It's easy for computers to parse and generate
  • It's compact for efficient transmission over networks
  • It maps directly to data structures in most programming languages (like Python dictionaries and lists)

JSON struck the right balance between simplicity, structure, and efficiency, which is why it became the default format for most modern web APIs.

Explain what the main status code ranges (2xx, 3xx, 4xx, 5xx) mean.

2xx Success: the request worked correctly. Everything is fine, and you can proceed with processing the response. The most common is 200 OK.

3xx Redirection: the resource has moved or the client should use another URL. Most HTTP libraries follow common redirects automatically.

4xx Client error: you made a mistake in your request. Wrong URL, missing parameters, invalid syntax, or lack of authentication. You need to fix your code or request.

5xx Server error: the server has a problem, and it's not your fault. The server might be down, overloaded, or experiencing an internal error. You should try again later.

Break down this URL into its components: https://api.example-weather.com/v1/forecast?city=London&units=metric
  • Protocol: https://, secure communication method
  • Domain: api.example-weather.com, which service we're talking to
  • Version: /v1, which API version to use
  • Path: /forecast, which resource on the server
  • Parameters: ?city=London&units=metric, specific details customising the request (which city and which measurement system)

This URL structure is common across many web APIs, making them predictable once you understand the pattern.

Looking forward

Chapter 2 gets practical. You'll set up your development environment properly, install the tools you need, and prepare to make your first API request. Then Chapter 3 delivers the payoff: you'll write code that makes real API calls and displays actual data. The concepts from this chapter will make sense when you see them working in your own programs.

You now have the mental model. You understand what APIs are, why they exist, and how they work conceptually. From here, the book turns that understanding into hands-on skill: calling APIs, reading their responses, and building useful programs around them.