APIs & Data: The Contracts and the State

A system's parts have to talk to each other and remember things. They talk through APIs — agreed contracts for requesting and returning information — and they remember through databases. You need the concepts here, not the syntax; the deep mechanics belong to other courses.

These two ideas, the contract and the state, are how every real system is wired together. Get them as concepts and a huge amount of technical conversation suddenly makes sense.

A restaurant menu is the perfect picture of an API. You order by name from the menu, the kitchen makes the dish and sends it out — and you never need to enter the kitchen or know how it's cooked. The menu is the agreed contract between you and the kitchen.

What an API Is

An API (application programming interface) is a contract: "send me a request in this form, and I'll send back this result." One part of a system offers an API; other parts use it by following the agreed format, without needing to know what happens inside. Cadence's app might call an API that says "save this check-in" or "give me my current streak" — it sends the request and gets an answer, while the messy internals stay hidden. An API is exactly the abstraction idea from earlier, applied to how two systems meet.

API Styles, Briefly

APIs come in a few common styles, named here so you'll recognize them. REST is the most common style on the web — simple request-and-response over HTTP, the same technology web pages use. You may also hear GraphQL (where the caller asks for exactly the data it wants) and gRPC (a fast style for services talking to each other). You don't need the differences yet — just know "API" usually means a request-response contract, and REST is the typical flavor.

Where Data Lives

Software needs memory that outlives a single moment — your habits should still be there tomorrow. That long-term memory is a database: organized storage that keeps data safe, lets many people use it at once, and enforces rules about its shape. It's far more than a big file or spreadsheet; a database is built to keep data consistent and intact even when many users hit it at the same time. The database is the system's lasting state.

SQL vs NoSQL

Databases come in two broad families. SQL (relational) databases store data in structured tables with strict columns — like a precise spreadsheet with enforced rules — and are great when the shape of the data is well known. NoSQL databases store data more flexibly, often as documents that can vary in shape, which suits data that's loose or rapidly changing. "NoSQL" doesn't mean "no structure"; it means flexible structure. Which family fits depends on the data — and that choice is a design decision, covered in depth in the database and cloud courses.

Cadence ties it together. The app talks to its backend through a small API — "save this check-in", "get my streak" — never touching storage directly. Behind that API sits a database holding users, habits, and check-ins: the system's long-term memory. The app asks; the API and database answer. The app stays simple precisely because the contract hides everything behind it.