API
application programming interface / web API / integration / REST API
An API is the way one piece of software talks to another without a person in the middle. MDN describes it as a contract between the application offering it and whatever uses it. The part that matters commercially is that the contract belongs to whoever publishes it, and it changes.
The definition is less technical than the acronym suggests. An API, an application programming interface, is a set of features and rules that exist inside a software program enabling interaction with it through software, as opposed to a human user interface. That last clause is the whole idea: it is the door built for other software rather than for a person clicking.
MDN then gives the framing worth carrying into a conversation about cost. The API can be seen as a simple contract, the interface, between the application offering it and other items, such as third-party software or hardware. A contract has two sides, and in almost every case the side that wrote it is not you.
Which leads to the fact most quotes leave out. A web API does not remain static. As business requirements change, new collections of resources are added, and Microsoft's guidance is blunt about the consequence: you must consider the effects that such changes have on client applications. The party publishing the API decides when that happens, and your integration is one of the client applications in that sentence.
Versioning is how a publisher manages that, and the options include not versioning at all. Microsoft describes the simplest approach directly: this approach is the simplest and can work for some internal APIs. Adding content to existing resources might not present a breaking change, because client applications that are not expecting to see this content ignore it. That is fine until the change is not additive, and nothing obliges an external publisher to keep it additive.
In practice
When a proposal says two systems will be connected by an API, the work being quoted is usually the connection. The risk that is not being quoted is the maintenance: the other side changes, your integration stops, and somebody has to notice. Asking who that somebody is turns an assumption into a line item.
Not the same as
- An integration
- The API is the published interface. The integration is the code you own that uses it. One is a document somebody else controls, the other is an asset you paid for.
- A data export
- A file of records is a snapshot you keep. An API call is a request to a system that has to be running, reachable and willing to answer.
Why it matters to you
Almost every modern quote contains at least one of these, and the word hides an ongoing dependency inside a one-off price. Knowing that an API is a contract written by the other party makes the right questions obvious, and they are commercial questions rather than technical ones: what happens when it changes, who is watching, and what does the business do in the meantime.
What to ask or check
- 01Whose API is this, and where do they publish changes?
- 02Is there a version we are pinned to, and what happens when it is retired?
- 03Who notices if it stops working, and what does the business do until it is fixed?
What people get wrong
That connecting to one is a finished job. The guidance says a web API does not remain static and that changes have effects on client applications, so an integration is a standing commitment rather than a delivery.
Red flags
- A quote that prices the connection and says nothing about maintaining it.
- Nobody able to name where the other party announces changes.
- An integration with no monitoring, so the first alert is a customer.
Who owns it
The publisher owns the interface and you own the code that uses it. The gap between those two is where the maintenance lives, and it belongs to somebody by name.
Where you will see it
In the line of a proposal that says the systems will talk to each other, and in the week it stops being true.