Exposed Service
Examples
Description
A component through which the system publishes functionality or information so that other systems can invoke it programmatically. The system acts as the provider: it defines a contract, opens access points, and handles the requests that arrive from external systems, returning responses or accepting data pushed into it. It hides the internal complexity and exposes only the operations allowed by the defined contract. It is the "server" side of an integration between systems.
Mandatory capabilities
Mandatory capabilities
- Publishes access points that external or internal systems can invoke programmatically
- Receives incoming requests, handles them against the system's logic, and returns a structured response
- Defines a contract (specification) that states how to make requests and what responses to expect
- Requires the client systems that invoke the service to be authenticated
Additional capabilities
Additional capabilities
- Versioning: maintains multiple versions of the API in parallel (v1, v2) so that existing clients do not break as the contract evolves
- Interactive documentation: provides a browsable interface to the specification (Swagger/OpenAPI, GraphQL Playground) where the service can be tried out directly
- Rate limiting: restricts the number of requests a client can make within a time interval
- Response caching: temporarily stores frequent responses to reduce response time and system load
- Usage monitoring: records metrics on invocations, latencies, errors, and consumption patterns per client
Boundaries
What it is not
- Is not the user interface: the exposed service is programmatic, meant to be consumed by another system, not for a person to interact with through a screen
- Does not consume third-party services — that belongs to External Service Consumption: here the system is the one offering, not the one using
- Does not verify the client's identity — that belongs to API Authentication
- Does not determine what the authenticated client can do — that belongs to Authorization
Information flow
Input
Structured request from an external system (invocation method, operation, parameters, credentials). In the data injection variant, the data itself that the third party sends for the system to incorporate.
→
Output
Structured response with the requested data or confirmation of the executed operation, in the format defined by the specification (JSON, XML, etc.)
Variants
- REST: an architecture based on resources and standard HTTP operations, typically with JSON responses
- SOAP: a formal protocol based on XML messages, common in banking and government systems
- GraphQL: lets the client specify exactly what information it needs in each request
Typical dependencies
- Server that receives and processes the incoming requests
- API Authentication to verify the client's identity
- Authorization to determine what the authenticated client can do
- Database or information repository the service operates on
- Documentation that specifies the access points and protocols
Mapping to the Digital Board
Manual UpdateNo
Automatic UpdateOptional
Data ConceptsAlways
On-Demand OutputsNo
Automatic OutputsAlways
Autonomous ProcessesAlways
| Section | Relationship | Notes |
|---|---|---|
| Manual Update | No | — |
| Automatic Update | Optional | When the service is exposed so that third parties can push data into the system (data injection variant). |
| Data Concepts | Always | The system entities exposed or manipulated through the service. |
| On-Demand Outputs | No | — |
| Automatic Outputs | Always | Structured responses the system sends to the requesting external systems. |
| Autonomous Processes | Always | The logic that handles each incoming request. Rate limiting, caching, and monitoring when those capabilities are present. |
Digital Board example
Manual Update
—
Data Concepts
Bus
Route
Arrival Time
On-Demand Outputs
—
Automatic Update
GPS Position Injection
Autonomous Processes
Request Handling
Rate Limiting
Automatic Outputs
Real-Time Position Response
Arrival Times Response