I’ve been thinking about API governance differently when working with multiple Go services.
With one API, keeping conventions consistent isn’t too difficult. With 10, 20, or more services, it becomes much harder.
Different teams can gradually introduce their own approaches to:
- Authentication
- Error responses
- Endpoint naming
- OpenAPI definitions
- API versioning
- Documentation
- Security requirements
Everything can still work, but the API landscape becomes inconsistent.
I’ve been testing Apidog as an API Governance Tool to see whether some of these rules can be moved from code reviews into automated checks.
What I find useful is being able to combine API development with:
- Endpoint Compliance Check
- Documentation Completeness Check
- Secret Scanner
- RBAC
- Audit Logs
The workflow I’m considering for Go services is:
Go service → OpenAPI → governance checks → API testing → CI/CD
The interesting part for me is that governance doesn’t necessarily have to block developers. It can simply provide an early warning when a new endpoint doesn’t follow the organization’s standards.
For teams running multiple Go services:
How do you currently keep API standards consistent?
Do you use custom Go tooling, OpenAPI linting, CI rules, or a dedicated API Governance Tool?
And at what point does maintaining your own governance rules become more work than using a dedicated tool?