Why OpenAPI is bad for Governance

This is the core weakness of OpenAPI when viewed through the lens of API governance. For OpenAPI to Support Governance, It Would Need:

1. 🔐 RBAC / ABAC Rules

OpenAPI would have to specify:

• Who can access each endpoint (roles, groups, permissions)
• What conditions must be true (ABAC: e.g., user.department == "HR")

Example of what’s missing:

# NOT supported natively
x-access-control:
  roles: ["admin", "supervisor"]
  attributes:
    department: "finance"

Right now, you have to do this outside OpenAPI, in tools like:

• OPA (Open Policy Agent) for policy decision
• Keycloak for identity-based rules
• Custom code or middleware

This makes it so you do not have a consolidated document for RULES/ACCESS.

2. Rate Limiting / Quotas

Governance requires:

• Per-user, per-key, or per-IP limits
• Burst handling, cooldowns, quota resets
• Tiered access plans (free vs premium)

OpenAPI has no standard fields for:

# NOT supported natively
x-rate-limit:
  requests_per_minute: 100
  burst: 10

Instead, you define rate limiting in:

• API gateways (e.g., Kong, Apigee, AWS API Gateway)
• Custom proxy layers
• External YAML files (e.g., Envoy config)

And as such, these will be bypassed entirely with ANY internal redirect.

3. Rule-Driven Behavior / Conditional Access

Governance also means:

• Time-based access (“only allowed 9–5 PM”)
• Stateful access (“only after verification”)
• Contextual logic (“block if from untrusted region”)

OpenAPI can’t express conditional logic, environments, or runtime policies.

So Why Do People Still Use OpenAPI?

Because it serves as:

• A contract for creating initial mappings and for testing
• A source of truth for endpoints, types, and shapes
• A beginners start point to plug into real governance tools

What Should Be Used With OpenAPI for True Governance?

Ideally, this can be accomplished through documents like the spring-boot-starter-beapi IO State files where all rules are consolidated into files based on the controller.

This also greatly decreases ‘api bloat’ so you only changes rules based on endpoints in certain controllers.

Final Word

OpenAPI cannot be used alone for API governance. It must be supplemented (or replaced) with tools that define and enforce rules, access control, and runtime behavior.

If you want to govern APIs at scale, OpenAPI should only be:

• The schema source
• Used in tandem with enforcement systems

Let me know if you’d like a recommended stack for secure, governed APIs (including RBAC/ABAC and rate limiting).