0% found this document useful (0 votes)
19 views12 pages

API Taxonomy Overview and Guidelines

The document outlines three types of APIs: System APIs for accessing core systems, Process APIs for orchestrating data across systems, and Experience APIs tailored for specific consumers. It compares these APIs based on parameters like complexity, maintainability, and security, and discusses various use cases and implementation guidelines. Additionally, it emphasizes the importance of API layering and governance for optimizing API design and integration.

Uploaded by

saibalghosh.au
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
19 views12 pages

API Taxonomy Overview and Guidelines

The document outlines three types of APIs: System APIs for accessing core systems, Process APIs for orchestrating data across systems, and Experience APIs tailored for specific consumers. It compares these APIs based on parameters like complexity, maintainability, and security, and discusses various use cases and implementation guidelines. Additionally, it emphasizes the importance of API layering and governance for optimizing API design and integration.

Uploaded by

saibalghosh.au
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

What are the different types of APIs?

● System APIs
These APIs provide a means of accessing core systems
of record and expose data from these systems, often in
a canonical format. They abstract the complexity of
underlying systems (such as databases, ERP, CRM) and
provide a consistent interface for data access.

● Process APIs
These APIs are responsible for orchestrating and
shaping data across multiple systems. They combine
and process data from various sources (often via
System APIs) to fulfill specific business processes or
logic, enabling reuse and agility.

● Experience APIs
These APIs are tailored to the needs of specific
consumers, such as mobile apps, web applications, or
external partners. They present data in the most
convenient format for the end user or channel, often
aggregating and transforming data from Process APIs.
Comparison
Parameter System APIs Process APIs Experience APIs

Complexity Low to moderate; focused on single systems Moderate to high; involves orchestration and business logic Low to moderate; focused on data presentation

Maintainability High; isolated from consumer changes Moderate; business logic may evolve High; changes are mostly UI/consumer-driven

Reusability High; generic and reusable across processes High; reusable business logic for multiple experiences Low to moderate; tailored for specific channels

Coarseness Fine-grained; exposes specific data entities Medium; aggregates and processes data Coarse-grained; aggregates and formats for end users

Stability High; changes infrequent, tied to core systems Moderate; changes with business processes Moderate; changes with consumer needs

Security Very high; often exposes sensitive data High; may enforce business-level security Moderate; focuses on channel-specific security

Flexibility Low; tightly coupled to backend systems High; adapts to business logic changes Very high; adapts quickly to UI/channel changes

Performance High; direct access to systems Moderate; may involve multiple data sources Variable; depends on data aggregation and formatting

Change Frequency Low; backend changes are rare Moderate; business logic changes periodically High; frequent updates for new experiences

Consumer Type Internal IT, integration teams Internal business processes, middleware End users, mobile/web apps, partners

Typical Use Case Expose database, ERP, CRM data Order processing, customer onboarding Mobile app dashboard, partner portal
Let’s take use case by use case?

[Link] have only one producer (e.g. only one payment provider)?

2. We have multiple producer for same domain (e.g. two or more payment provider).

3. We have a producer and a consumer which have connectors already built for some industry
standard APIs but the producer does not conforms to it.

3. We have multiple producer for same domain and multiple consumers.

4. Anything else!!!!!!
Pros & Cons - All Passthrough API
API Layering : Pros & Cons
Pragmatic API Layering Framework

Decision Matrix

Factor Passthrough Approach Layered Approach

Reuse potential Low High

Integration complexity Simple Complex

Time sensitivity Urgent Strategic

Business criticality Low High

Change frequency Rare Frequent


Implementation Guidelines
Classify by Business Impact

● Critical business capabilities → Full API layering


● Low-impact, one-off integrations → Passthrough acceptable

Start Simple, Layer Later

● Begin with minimal viable API design


● Refactor into layers when reuse patterns emerge
● Document technical debt for future refactoring

Hybrid Patterns

● "System-Experience" pattern for simple domains (skip Process layer)


● "Process-Experience" pattern when systems are stable
● Full layering for complex, high-change domains

Governance Checkpoints

● Review APIs quarterly for refactoring candidates


● Identify passthrough APIs with increasing usage
● Upgrade high-value passthrough APIs to layered approach

Practical Metrics

● API reuse rate (calls per month)


● Change request frequency
● Integration delivery time
● Maintenance effort
Closing Thoughts
Closing Thoughts
Thank You

You might also like