Yeah. I think that nails it. If we had something like an openapi specification or Swagger spec
- the reference guide could be generated
- We can verify/test code and check for breaking changes
- Generate and verify clients from the api specification
- Build/contribute additional tooling around the specification
Those would be great.
Incidentally, we actually have tests for verifying stuff like the
curlexamples in the API Definitions. If you want to try the tests yourself, they're right over here:https://github.com/steemit/devportal#tests
And we also generate/verify the API Spec here:
https://github.com/steemit/devportal#managing-api-definitions
When I said generated, I meant from the actual source code. I'm basically suggesting a literate programming approach with specification as code.
Like if @inertia made changes to the json-rpc, then specification changes would be accepted in the same PR. In the next CI build, documentation could be generated, but that's not what's important. What's important is that now the specification itself is deployed with the software and can be used to generate/verify a client.
From a single change, you have now affected several facets.