TECHNOLOGIES

API

Application Programming Interface

The agreed contract through which one piece of software talks to another, without either side needing to know how the other works inside.

Last reviewed: 2026-06-02 byKevin Riedl wiki β†—

An API is the defined way one piece of software talks to another. It says: here are the things you can ask me to do, here is exactly how you ask, and here is what you get back. The whole point is that the caller does not need to know how the work is done internally, only what to send and what to expect. Your phone’s weather app does not know how the weather service works. It just knows the API, sends a request, and gets a forecast.

The key idea is the contract. Both sides agree on the shape of the requests and responses, and as long as that contract holds, either side can change its internals freely. The two common styles you will hear about are REST, which models everything as resources you read and write over standard web requests and is the default for most web and mobile backends, and GraphQL, which lets the caller ask for exactly the fields it wants in one request. Both are just disciplined ways of defining the same contract.

API design is one of the most durable decisions you make. Internal code you can refactor over a weekend. A public API has other people’s software depending on the exact shape of it, so changing it breaks their integrations, which means you often cannot change it at all without a painful versioning exercise. A clean, well-named, consistent API ages well. A sloppy one becomes a permanent tax you pay on every future change. We treat API design as a first-class part of software development, not an afterthought bolted on at the end.

The honest take: most “the integration is a nightmare” complaints trace back to an API that was designed in a hurry to ship one feature, then forced to carry ten. Spend the time on the contract early. It is the part you will least be able to change later.

// FAQ

FAQs

FAQs

The agreed way one piece of software asks another to do something. It defines what you can request, how to request it, and what you get back, so the caller never needs to know how the other side works inside. Apps use APIs to talk to backends and to each other constantly.
REST models everything as resources you read and write over standard web requests, and it is the default for most backends. GraphQL lets the caller ask for exactly the fields it wants in a single request. Both are disciplined ways of defining the same kind of contract between caller and service.
Because once other software depends on your API, changing it breaks their integrations, so you often cannot change it without a painful versioning exercise. Internal code is easy to refactor. A public API contract is one of the hardest decisions to reverse, so it is worth getting right early.