I’ve been fascinated about API governance otherwise when working with a number of Go providers.
With one API, retaining conventions constant isn’t too tough. With 10, 20, or extra providers, it turns into a lot tougher.
Totally different groups can regularly introduce their very own approaches to:
- Authentication
- Error responses
- Endpoint naming
- OpenAPI definitions
- API versioning
- Documentation
- Safety necessities
All the things can nonetheless work, however the API panorama turns into inconsistent.
I’ve been testing Apidog as an API Governance Instrument to see whether or not a few of these guidelines will be moved from code evaluations into automated checks.
What I discover helpful is with the ability to mix API growth with:
- Endpoint Compliance Examine
- Documentation Completeness Examine
- Secret Scanner
- RBAC
- Audit Logs
The workflow I’m contemplating for Go providers is:
Go service → OpenAPI → governance checks → API testing → CI/CD
The fascinating half for me is that governance doesn’t essentially have to dam builders. It may well merely present an early warning when a brand new endpoint doesn’t comply with the group’s requirements.
For groups operating a number of Go providers:
How do you at present maintain API requirements constant?
Do you employ customized Go tooling, OpenAPI linting, CI guidelines, or a devoted API Governance Instrument?
And at what level does sustaining your individual governance guidelines change into extra work than utilizing a devoted device?
We’re utilizing Linters with Guidelines (generally it’s as straightforward as forbidding the usage of sure packages/strategies.
However the simplest methodology we use is offering a fundamentals library with useful features for all duties which seem in a number of providers (like authentication, error responses, API definition, documentation, safety, …)
Folks will use the company-standard, if it’s the best solution to clear up an issue. So most of my focus is on making our most popular means of doing issues so intuitive and straightforward, will probably be most popular over various options (like writing your individual Auth handler). After that the Linter is simply to shut the gaps the place the “dangerous” answer is simply too straightforward and can’t be prevented by API design – however that is at all times the final measure, not an answer for unintuitive or leaky APIs.
