API style describes the architectural and design choices for a programming interface (e.g., REST, GraphQL, gRPC), defining resource models, communication patterns, and error handling. Choosing an API style has strong effects on scalability, consistency, integration, and operations and requires trade-offs between simplicity, performance, and interoperability.
Use this profile to understand the building block briefly, place it in the model, and switch to the 360° assessment when needed.
API style describes the architectural shape of an interface and defines how it organizes data, calls, and errors between systems.
API styles emerged from the practical need to shape interfaces between separate systems so behavior, errors, and room for change stay clear for people and tools. As software moved from local program interfaces to web APIs, teams needed describable contracts and comparable patterns. Specifications such as OpenAPI made this kind of interface description systematically usable for HTTP APIs.
Think of an API style as the rulebook for a door between systems. It decides whether the door is resource-oriented, query-oriented, or call-oriented, how messages are formatted, which responses are possible, and how errors, versions, and security are exposed. The chosen style therefore shapes not only the technology, but also the room for clients, documentation, and future change.
The interface is the agreed boundary between software components.
An architectural style for client-server communication based on resources and HTTP.
A query language with a runtime that lets clients request exactly the data they need.
An RPC framework for clearly defined remote calls with efficient transfer.
The style specifies expectations for inputs, outputs, and allowed changes so integration stays reliable.
It must be clear how a system expresses failure, partial failure, and retryability.
API style helps when selecting or evaluating an interface and more than one communication form is possible. The choice affects client complexity, performance, caching, governance, and evolvability. No style is universally best: resource orientation, flexible queries, and efficient remote calls optimize for different priorities. A later switch is often expensive because clients, documentation, and tooling are tied to the contract.
Where this building block is located in the topic model.
Explore how this building block connects to concepts, methods, technologies, and tools.
These sources establish the term and its professional meaning.
All direct connections of the current building block in a compact text view.
This classification shows where the building block typically matters, how demanding it is, and what kind of impact it has in the model.
The level within the organization (enterprise, domain, team) at which the AssetBlock is applied.