An interface is a governed boundary through which two people, systems, components or organisations exchange information, material, control or service.
A classroom handoff, software API, electrical connector, form, dashboard, service desk, payment gateway and contract can all act as interfaces. What matters is not appearance but the contract that defines what may cross the boundary, in what form, under whose authority and with what failure behaviour.
Quick answer: how should interfaces be categorised?
- Boundary: which two domains meet?
- Contract: what is promised or required at the boundary?
- Input and output: what crosses and in which direction?
- Protocol: what sequence, format or language is used?
- Compatibility: what versions or standards can connect?
- Ownership: who maintains each side?
- Observability: can failures and state be seen?
- Security and rights: who may access or transmit what?
- Failure mode: what happens when the interface breaks?
- Version: how does change remain compatible?
This article complements How to Categorise Relationships and How to Categorise Dependencies: an interface is the operational boundary where a relationship or dependency is actually exercised.
Interface is not the same as connection
Two things can be connected physically or logically without having a well-defined interface. Interfaces add expectations, formats, roles and allowable behaviour.
Human interfaces organise communication
Forms, reports, meetings and service counters define how requests arrive, how information is represented and how responses are returned.
Machine interfaces organise technical exchange
Ports, APIs, message queues and connectors define allowable inputs, outputs, timing and error behaviour.
Organisational interfaces govern handoffs
One department may hand a case to another under a service-level expectation, approval rule or shared data contract.
Physical interfaces constrain geometry and material
Mechanical fittings, plugs and mounting points depend on dimensions, tolerances and environmental requirements.
Informational interfaces depend on representation
Field names, units, identifiers and semantics determine whether the receiver interprets transmitted data correctly.
Contract-first interfaces make obligations visible
Inputs, outputs, preconditions, postconditions, errors and version rules are defined before implementation details are considered.
Loose interfaces trade control for flexibility
Natural language and informal handoffs adapt easily but may create ambiguity and hidden assumptions.
Strict interfaces improve interoperability
Formal schemas and protocols reduce interpretation freedom and make automated validation easier.
Directionality matters
Read-only, write-only, bidirectional and request-response interfaces permit different actions and therefore create different risks.
Synchronous and asynchronous interfaces differ in timing
Synchronous exchange expects immediate coordination; asynchronous exchange decouples time but requires stronger state, queue and retry handling.
Stateful and stateless interfaces differ in memory
A stateful interaction depends on prior context; a stateless one carries enough information for each exchange to stand independently.
Version compatibility deserves explicit classification
Backward-compatible, forward-compatible, breaking and deprecated interfaces should not be treated as equivalent.
Semantic compatibility is deeper than format compatibility
Two systems can exchange valid fields while assigning different meanings to the same label. Shared syntax does not guarantee shared semantics.
Authentication and authorisation are different interface properties
Authentication asks who is connecting. Authorisation asks what that identity may do through the interface.
Failure behaviour belongs in the contract
Timeout, retry, reject, queue, degrade, fail closed and fail open are materially different outcomes when communication fails.
Idempotency matters for repeated requests
If the same operation is repeated after an uncertain outcome, a well-designed interface should define whether duplication can occur and how it is reconciled.
Observability reduces ambiguity
Status, receipts, logs and error codes help distinguish attempted exchange from accepted, processed and completed exchange.
Interface ownership must be split carefully
Provider and consumer can each own different responsibilities. Shared boundaries fail when both assume the other side monitors compatibility and change.
Interfaces can become bottlenecks
Capacity, latency, manual review or one specialist handoff can limit the throughput of a much larger system.
Interfaces concentrate change risk
Changing one side without checking dependent consumers can create widespread downstream failure even when the changed component works correctly in isolation.
A practical interface record
- interface ID and name;
- provider and consumer;
- boundary and purpose;
- inputs and outputs;
- protocol and format;
- preconditions and postconditions;
- permissions;
- capacity and latency;
- error and retry behaviour;
- compatibility rules;
- owner on each side;
- observability;
- dependencies;
- version and deprecation state.
The deeper idea
Interfaces are promises at boundaries. They let complex systems evolve separately without requiring every component to know how every other component works internally.
To categorise an interface well is to preserve what crosses the boundary, under what contract, between which owners, with what compatibility and what happens when the exchange fails.
Final answer
Categorise interfaces by boundary, contract, inputs, outputs, protocol, direction, compatibility, ownership, observability, permissions and failure mode. Keep interface separate from mere connection, preserve semantic as well as technical compatibility, and version consequential changes so dependent systems can adapt safely.