API as Contract - What Is A Good Api | OneNoughtOne

0/246

System Design (LLD)API & Interface Design

What Is a Good API?

LevelIntermediate

Duration60 mins

TopicAPI & Interface Design

1 / 4

API as Contract

The Foundation of Software Integration

Every piece of software you've ever used—from the apps on your phone to the microservices powering global platforms—communicates through Application Programming Interfaces (APIs). These interfaces are the invisible handshakes between software components, enabling systems written in different languages, running on different machines, and maintained by different teams to collaborate seamlessly.

But what elevates an API from merely functional to genuinely excellent? The answer begins with understanding a powerful mental model: an API is a contract.

This concept—API as contract—isn't mere metaphor. It's a design philosophy that, when fully embraced, transforms how you think about interface design. It shapes your decisions about naming, error handling, versioning, and documentation. It determines whether developers integrate your API in minutes or struggle for days.

What You Will Learn

By the end of this page, you will understand: (1) Why treating APIs as contracts creates superior interfaces, (2) The anatomy of an API contract including its guarantees and obligations, (3) How to design contracts that enable independent evolution of producer and consumer, and (4) The relationship between contracts, trust, and developer experience.

Understanding API as Contract

A legal contract establishes clear terms between parties: what each party promises to deliver, what each party expects to receive, and what happens when those expectations aren't met. An API contract operates on precisely the same principle.

When you expose an API—whether it's a public method on a class, a REST endpoint, or a GraphQL schema—you're making a promise to consumers. This promise encompasses:

Components of an API Contract

•Signature — The method name, parameters (their types, order, and optionality), and return type. This defines how to call the API.
•Preconditions — What must be true before calling the API. What state must exist? What parameters are required? What constraints must be satisfied?
•Postconditions — What will be true after the API successfully completes. What state changes? What results are returned?
•Invariants — What remains unchanged regardless of API calls. What guarantees persist across operations?
•Error conditions — When and how the API fails. What errors are possible? How are they communicated?
•Side effects — What observable effects occur beyond the return value. What resources are created, modified, or consumed?

The Two-Party Agreement:

Every API contract implies a two-party agreement:

The Provider's Promise (API Implementer): "If you call me correctly—satisfying my preconditions with valid inputs—I guarantee to produce the specified result, maintain the specified invariants, and if something goes wrong, communicate failure in the documented manner."
The Consumer's Obligation (API Caller): "I will call you with valid inputs that satisfy your preconditions. I will handle your return values appropriately. I will respond to your error signals gracefully."

Breaking either side of this agreement leads to system failures. If the provider violates its guarantees, consumers cannot build reliable systems. If consumers violate preconditions, the provider's behavior becomes undefined.

The Fundamental Insight

Treating APIs as contracts shifts your mindset from 'making it work' to 'making it reliable.' You stop asking 'Will this function run?' and start asking 'What am I promising to every caller, forever?'

Expressing Contracts in Code

The contract concept isn't merely philosophical—it manifests concretely in code. Let's examine how contracts appear across different interface styles:

Method Signatures as Contracts:

Consider a simple method signature:

UserService.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
interface UserService {
    /**
     * Retrieves a user by their unique identifier.
     * 
     * @param userId - The unique identifier of the user to retrieve.
     *                 Must be a positive integer.
     * 
     * @returns The User object if found.
     * 
     * @throws UserNotFoundError if no user exists with the given ID.
     * @throws InvalidArgumentError if userId is null, undefined, or non-positive.
     * @throws ServiceUnavailableError if the underlying data store is unreachable.
     * 
     * Contract:
     * - PRE: userId > 0
     * - POST: result.id === userId (if no error thrown)
     * - INVARIANT: The returned user object is immutable
     * - SIDE EFFECTS: None (read-only operation)
     */
    getUserById(userId: number): Promise<User>;
}

Notice how the contract is expressed through:

Type system: The parameter type number/Long/int and return type Promise<User>/User encode basic constraints
Documentation: JSDoc/Javadoc comments describe semantics the type system cannot express
Exception declarations: Explicit listing of error conditions
Formal contract specification: Preconditions, postconditions, invariants, and side effects

The Type System as Contract Enforcement:

Modern type systems serve as automated contract verification. Consider how types express and enforce contracts:

ContractsViaTypes.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
// Types express contracts that the compiler enforces
 
// A branded type that guarantees positive integers
type PositiveInteger = number & { readonly __brand: 'PositiveInteger' };
 
function toPositiveInteger(n: number): PositiveInteger {
    if (!Number.isInteger(n) || n <= 0) {
        throw new Error(`Expected positive integer, got ${n}`);
    }
    return n as PositiveInteger;
}
 
// Now the contract is enforced at compile time
interface UserServiceStrict {
    // Consumers must provide a validated PositiveInteger
    // The type system ensures the precondition is met
    getUserById(userId: PositiveInteger): Promise<User>;
}
 
// Usage: compile-time contract enforcement
const service: UserServiceStrict = /* ... */;
 
// This compiles - contract satisfied
const validId = toPositiveInteger(42);
service.getUserById(validId);
 
// This fails to compile - contract violated
// service.getUserById(-5);  // Type error!
// service.getUserById("abc"); // Type error!

Design by Contract

This approach—formally specifying preconditions, postconditions, and invariants—is called 'Design by Contract,' pioneered by Bertrand Meyer in the Eiffel programming language. While most languages lack built-in contract verification, the mental model remains invaluable for API design.

The Anatomy of API Guarantees

A mature API contract encompasses multiple dimensions of guarantees. Understanding these dimensions helps you design comprehensive contracts that leave no ambiguity about what consumers can rely upon.

Behavioral Guarantees:

These describe what the API does functionally:

Behavioral Contract Elements

•Functional behavior: What transformation does the API perform on its inputs? What are the outputs?
•Idempotency: Can I call this operation multiple times with the same inputs and get the same result? Is it safe to retry?
•Ordering guarantees: If I call operations in sequence, what ordering guarantees exist? Are results returned in a specific order?
•Atomicity: Does the operation complete entirely or not at all? Are partial results possible?
•Determinism: Given the same inputs and state, will the result always be the same?

Performance Guarantees:

These establish expectations about non-functional characteristics:

Performance Contract Elements
Guarantee Type	Description	Example
Latency bounds	Maximum response time under normal conditions	getUserById returns within 100ms at p99
Throughput limits	Maximum request rate the API can sustain	Rate limited to 1000 requests/minute
Timeout behavior	What happens when operations take too long	Operations timeout after 30s with TimeoutError
Resource consumption	Memory, CPU, or other resource usage bounds	Batch operations process at most 1MB per request
Concurrency semantics	Behavior under concurrent access	Thread-safe for concurrent reads, serialized writes

Durability Guarantees:

For APIs that manage persistent state:

Durability Contract Elements

•Persistence: When does data become durable? Immediately on return, or eventually?
•Consistency: What consistency model applies? Strong consistency, eventual consistency, causal consistency?
•Recoverability: What survives failures? System crashes, network partitions, data center outages?
•Retention: How long is data retained? Are there automatic cleanup policies?

Evolution Guarantees:

These define how the API changes over time:

Evolution Contract Elements

•Backward compatibility: Will new versions continue to work with existing clients?
•Forward compatibility: Will old versions work with new client requests?
•Deprecation policy: How are features retired? What notice is given?
•Version support: How long are old versions maintained?
•Migration path: What assistance is provided for upgrades?

Implicit vs. Explicit Guarantees

Every API makes guarantees—the question is whether they're explicit or implicit. Implicit guarantees are dangerous: consumers assume behaviors that aren't promised, then their systems break when those behaviors change. Make guarantees explicit through documentation, types, and tests.

Contract Violations and Error Handling

Contracts clarify responsibility when things go wrong. Every error falls into one of two categories:

1. Consumer Violations (Client Errors):

The consumer failed to meet preconditions. This is the caller's fault:

Provided invalid input (wrong type, format, or range)
Called the API in an invalid state (unauthorized, rate-limited)
Violated sequencing requirements (operations out of order)

2. Provider Failures (Server Errors):

The provider failed to meet postconditions despite valid input. This is the implementation's fault:

Internal logic errors (bugs)
Dependency failures (database down, external service unavailable)
Resource exhaustion (out of memory, disk full)

Error Categorization Determines Response:

Error Response by Category
Error Category	Who's Responsible	Should Retry?	HTTP Equivalent
Invalid input	Consumer	No (fix input first)	400 Bad Request
Missing authentication	Consumer	No (authenticate first)	401 Unauthorized
Insufficient permissions	Consumer	No (get permissions)	403 Forbidden
Resource not found	Consumer (usually)	No (resource doesn't exist)	404 Not Found
Conflict with current state	Consumer	Maybe (resolve conflict)	409 Conflict
Rate limit exceeded	Consumer	Yes (after delay)	429 Too Many Requests
Internal server error	Provider	Yes (transient)	500 Internal Error
Dependency unavailable	Provider	Yes (transient)	503 Service Unavailable

Contract-Centric Error Design:

When designing error handling, think in terms of contract violations:

ContractErrorDesign.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
// Error hierarchy based on contract violations
 
// Base class for all API errors
abstract class ApiError extends Error {
    abstract readonly category: 'client' | 'server';
    abstract readonly retryable: boolean;
}
 
// Consumer violated preconditions
class PreconditionViolationError extends ApiError {
    readonly category = 'client' as const;
    readonly retryable = false;
    
    constructor(
        public readonly parameter: string,
        public readonly requirement: string,
        public readonly actual: unknown
    ) {
        super(
            `Precondition violated: ${parameter} must ${requirement}, ` +
                                        `but was ${JSON.stringify(actual)}`
        );
    }
}
 
// Provider failed to meet postconditions
class PostconditionViolationError extends ApiError {
    readonly category = 'server' as const;
    readonly retryable = true; // Usually indicates a bug or transient issue
    
    constructor(message: string) {
        super(`Postcondition violated: ${message}`);
    }
}
 
// Usage in implementation
function getUserById(userId: number): Promise<User> {
    // Check preconditions - consumer's responsibility
    if (!Number.isInteger(userId) || userId <= 0) {
        throw new PreconditionViolationError(
            'userId',
            'be a positive integer',
            userId
        );
    }
    
    // Attempt operation
    const user = database.findUser(userId);
    
    // Verify postconditions - our responsibility
    if (user && user.id !== userId) {
        // This shouldn't happen - indicates a bug
        throw new PostconditionViolationError(
            `Retrieved user.id (${user.id}) doesn't match ` +
                                        `requested userId (${userId})`
        );
    }
    
    return user;
}

The Fail-Fast Principle

Check preconditions early and fail immediately with clear error messages. This helps consumers quickly identify and fix contract violations, rather than propagating bad data through the system where failures become harder to diagnose.

Contracts Enable Independent Evolution

One of the most powerful benefits of treating APIs as contracts is decoupling. When contracts are well-defined, producers and consumers can evolve independently:

The Substitution Principle:

If both parties honor the contract, the implementation behind the API can change completely without affecting consumers. This is the Liskov Substitution Principle applied to APIs:

Any implementation that satisfies the contract can be substituted
Consumers depend on the contract, not the implementation
Providers can optimize, refactor, or rewrite freely within contract bounds

ContractSubstitution.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
// Contract definition (the interface)
interface PaymentGateway {
    /**
     * Processes a payment transaction.
     * 
     * PRE: amount > 0, currency is valid ISO 4217 code
     * POST: Returns transaction ID on success
     * THROWS: PaymentDeclinedError if card declined
     * THROWS: InvalidAmountError if amount <= 0
     */
    processPayment(amount: number, currency: string): Promise<string>;
}
 
// Original implementation: Stripe
class StripeGateway implements PaymentGateway {
    async processPayment(amount: number, currency: string): Promise<string> {
        // Uses Stripe SDK
        const response = await stripe.charges.create({ amount, currency });
        return response.id;
    }
}
 
// New implementation: Different provider
class AdyenGateway implements PaymentGateway {
    async processPayment(amount: number, currency: string): Promise<string> {
        // Uses Adyen SDK - completely different implementation
        const response = await adyen.payments.create({ 
            amount: { value: amount, currency } 
        });
        return response.pspReference;
    }
}
 
// Consumer code doesn't change at all
class CheckoutService {
    constructor(private gateway: PaymentGateway) {}
    
    async checkout(cart: Cart): Promise<Order> {
        // Works with Stripe, Adyen, or any future implementation
        const txnId = await this.gateway.processPayment(
            cart.total, 
            cart.currency
        );
        return new Order(cart, txnId);
    }
}

Contract Stability Enables Team Parallelism:

In large organizations, stable API contracts are essential for scaling engineering:

Team A owns the user service and its contract
Team B consumes the user service to build notifications
Team C consumes the user service for analytics

As long as Team A maintains the contract, Teams B and C can develop independently. They don't need to coordinate deployments or worry about implementation details. They simply trust the contract.

The Contract as Coordination Mechanism:

How Contracts Reduce Coordination Costs

•No synchronous communication needed: Teams agree on contracts once, then work independently
•Clear ownership boundaries: Contract defines exactly where one team's responsibility ends
•Explicit change management: Contract changes are deliberate, versioned, and coordinated
•Independent testing: Each team can test against the contract, not against live dependencies
•Deployment freedom: Services can deploy independently as long as contracts are honored

Contract-First Development

Some teams adopt 'contract-first' development: defining the API contract before any implementation. This ensures the contract truly represents what consumers need, prevents implementation details from leaking into the interface, and enables parallel development from day one.

Contracts and Trust

Beyond technical considerations, API contracts establish trust—the foundation of developer experience.

Trust is Earned Through Reliability:

When your API consistently honors its contract:

Developers believe your documentation
Edge cases behave as specified
Errors are meaningful and actionable
Breaking changes are communicated and managed

This trust compounds over time. Developers who trust your API recommend it to others, build confidently upon it, and forgive occasional issues.

Trust is Destroyed by Contract Violations:

When your API violates its contract—even occasionally—trust erodes rapidly:

Trust-Destroying Behaviors

•Silent behavior changes: Changing semantics without version bumps or notice
•Undocumented limitations: Real constraints not reflected in documentation
•Inconsistent error handling: Sometimes returning errors, sometimes failing silently
•Surprise deprecations: Removing features without adequate warning
•Documentation drift: Documentation that doesn't match actual behavior
•Breaking 'optional' contracts: Changing behavior that consumers relied on but wasn't formally guaranteed

The Cost of Lost Trust:

Once trust is lost, developers:

Add defensive code and workarounds (increasing their maintenance burden)
Write extensive integration tests against your behavior (instead of trusting your unit tests)
Hesitate to adopt new features (assuming they might also have hidden issues)
Consider migrating to alternatives (the ultimate rejection)

Building Trust Through Contracts:

Trust-Building Practices

•Underpromise, overdeliver: Promise less than you're confident you can sustain, then exceed expectations
•Make contracts explicit: Document everything, even 'obvious' behaviors that might change
•Test contracts, not implementations: Your tests should verify contract compliance, ensuring consistency across refactors
•Treat contract changes as breaking: Any behavioral change that could surprise consumers is a breaking change
•Communicate proactively: Announce changes before they happen, with clear migration guidance
•Version honestly: If behavior changes, the version should reflect it

Hyrum's Law

"With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody." This law highlights why you should minimize observable behaviors beyond the contract—because someone will rely on them.

Designing Contract-First APIs

How do you apply the contract mindset when designing new APIs? Follow these principles:

1. Start with Use Cases, Not Implementation:

Define the contract from the consumer's perspective:

What problems do consumers need to solve?
What information do they need to provide?
What results do they expect?
How should errors be communicated?

2. Choose the Right Abstraction Level:

Contracts should be:

High enough to hide implementation details (consumers shouldn't know how it works)
Low enough to express meaningful operations (not so abstract as to be useless)
Stable at their abstraction level (able to accommodate implementation changes)

AbstractionLevels.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
// Too Low: Exposes implementation details
interface StorageService {
    // Leaks that we use PostgreSQL
    executeSqlQuery(sql: string): Promise<Row[]>;
    
    // Leaks internal file structure
    writeToFile(path: string, content: Buffer): Promise<void>;
}
 
// Too High: Not actionable
interface DataService {
    // What kind of operations? This tells us nothing
    performOperation(data: unknown): Promise<unknown>;
}
 
// Just Right: Meaningful operations, hidden implementation
interface DocumentStore {
    /**
     * Stores a document with the given key.
     * If a document with this key exists, it's replaced.
     * 
     * PRE: key is non-empty string, document is valid JSON-serializable object
     * POST: Document is durably stored and retrievable by key
     */
    store(key: string, document: object): Promise<void>;
    
    /**
     * Retrieves a document by key.
     * 
     * PRE: key is non-empty string
     * POST: Returns document if found, null if not found
     * INVARIANT: retrieve(key) returns what was stored at key
     */
    retrieve(key: string): Promise<object | null>;
    
    /**
     * Deletes a document by key.
     * 
     * PRE: key is non-empty string
     * POST: Document no longer exists, idempotent (ok to delete non-existent)
     */
    delete(key: string): Promise<void>;
}

3. Make Constraints Explicit:

Don't leave constraints to discovery:

Implicit Constraints

•"Username must be unique"
•"Maximum 100 items per page"
•"File size limit: 10MB"
•"Rate limited to 100/min"

Explicit Contract

•UsernameConflictError in throws clause
•pageSize: 1-100 in parameter docs
•maxContentLength in request schema
•X-RateLimit-* headers in spec

4. Define Error Contracts as Carefully as Success Contracts:

Errors are part of the API surface. Specify:

All possible error conditions
The structure of error responses
How to distinguish error types
Whether operations are safe to retry
Specific codes or types for each failure mode

5. Write the Contract Before the Implementation:

Contract-first development means:

Design the interface (signature, documentation, error conditions)
Write contract tests that verify behavior
Review the contract with consumers
Implement to satisfy the contract
Verify implementation passes contract tests

Contract as Specification

When done well, the contract serves as both specification and documentation. It tells consumers exactly what they can rely on, tells implementers exactly what they must provide, and tells testers exactly what to verify.

Summary: API as Contract

We've established the foundational concept that distinguishes well-designed APIs from those that merely function: the mental model of API as contract.

This conceptual framework will inform everything that follows in this module. Let's consolidate the key insights:

Key Takeaways

•An API contract includes: signature, preconditions, postconditions, invariants, error conditions, and side effects—the complete promise you make to consumers.
•Contracts are two-way agreements: Providers promise behavior, consumers promise to call correctly. Both sides have obligations.
•Express contracts in code: Use types, documentation, and formal specifications to make contracts explicit and verifiable.
•Contracts span multiple dimensions: Behavioral, performance, durability, and evolution guarantees all matter.
•Error handling is contract-bound: Distinguish consumer violations from provider failures. Design error responses as carefully as success responses.
•Contracts enable independence: Well-defined contracts let teams evolve implementations without coordinating with consumers.
•Trust is built on contract compliance: Consistently honoring contracts builds developer trust; violations destroy it quickly.
•Design contract-first: Start with consumer needs, choose the right abstraction, make constraints explicit, and define error contracts thoroughly.

What's Next:

Understanding that APIs are contracts is the foundation. The next page explores usability principles—how to design contracts that aren't just correct, but also intuitive, discoverable, and pleasant to use. A technically perfect contract that confuses developers is still a failed API.

Page Complete

You now understand the foundational concept of API as contract. This mental model—treating every API as a formal agreement with specific guarantees and obligations—is the lens through which all subsequent design decisions should be viewed.