APIs, without the computer science
7 min read
An API is a request and a response, nothing more mysterious than that. One system asks another system for something in a format they have both agreed on in advance, and the second system answers.
The clinical version
Think of a consult request. You send a specific, structured question to a specific service. You do not get to ask it however you like; there is a form, and the form is the point. The consulting service reads your request, does its work, and sends back a structured answer you can act on. An API is that same pattern between two pieces of software.
Why it matters here
Health informatics work is mostly about getting systems that were never designed to talk to each other to exchange information reliably. An API is the contract that makes that possible: a defined request format, a defined response format, and an expectation both sides honour. When that contract breaks (a field renamed, a value type changed), the two systems stop agreeing, and someone gets paged.
What changes once you see it
You will start reading integration diagrams differently. Every arrow between two boxes is a promise about a request and a response. When something is described as well-documented, what is actually being praised is a clear, stable contract. That is the whole idea. Everything past this point is detail.