Cheat sheets, gotchas & demos

Rule of thumb: pick one per API program and govern it consistently. Both are first-class on Anypoint; the choice is team and ecosystem fit, not capability.

A minimal ruleset encoding two common standards:

rules:
  must-have-version:
    message: API must declare a version
    severity: error
    given: $
    then:
      field: version
      function: truthy
  secured-by-default:
    message: Every operation should declare a security scheme
    severity: warning
    given: $.paths[*][*]
    then:
      field: security
      function: truthy

Publish the ruleset to Exchange, apply it to an API set, and read the conformance report. Start rules at warning, promote to error as teams adapt.

The most common governance failure: a "small fix" that quietly breaks consumers.

• Removing or renaming a field is MAJOR, not a patch.
• Tightening validation (e.g. making an optional field required) is breaking.
• Changing a response status code or error shape is breaking.

Coach the one question before publishing: could an existing consumer break? If yes, it is a new major version — a separately consumable asset, not an in-place edit.

Rolling out rulesets as hard error-level blocks on day one breeds resentment and workarounds.

• Introduce new rules as warnings first; surface gaps before enforcing.
• Give authors fast, local / CI feedback, not a surprise in a program review.
• Watch for a C4E bottleneck — if every spec waits on central approval, governance has become a gate, not an enabler.

The target state is governance developers barely notice because conformance is the default.

A tight live sequence that lands the parallel-work moment:

1. Create a tiny spec in API Designer (one resource, one or two methods).
2. Add an example to the response.
3. Toggle the mocking service to get a live base URL.
4. Call the mock from a REST client — real response, no implementation.
5. Point out: a consumer team could start right now, in parallel.

Keep it under ten minutes. The goal is the "oh — the backend doesn't exist yet" reaction.

Show governance as an enabler, not an audit:

1. Open a spec that violates a standard (missing version, no error responses).
2. Apply a ruleset in API Governance and show the conformance report.
3. Fix the spec; re-run and show it pass.
4. Mention the same check can run in CI so non-conforming changes never merge.

Frame it as fast feedback for authors — the standard helping teams, not policing them.