Hello everyone,<p>I've sort of come to the conclusion that I prefer writing API-specification (Open API in this case) before starting to write the application itself.<p>The reason mainly being that if one writes the specification first, one has to think through the api, its error codes an so forth. There is nothing wrong with going the other way, namely generating the specification from the code. However, I have this intuition that there will always be edge cases where you will end up having to manually write parts of the specification anyways.<p>This means that there is a great risk that the specification drifts from the implementation as the application/specification matures. The reason being is that one has to manually make sure that the specification matches the application, which is bound to be error prone!<p>My question is basically, how would you approach this problem? Do you know any tools that can help one make sure the specification matches the application? I've looked through some of the "Open API tools" [1], but none of them seem to really fully solve the problem.<p>Thank you for your time :D<p>[1] https://openapi.tools/
Great question! It fractally occurs at every level of the stack, I dealt with it when formally verifying operating systems, compilers, and runtimes: what do we mean by correct, and how can we assure our implementation has that property? You have the right instinct that it's important to have a specification.<p>One approach is to use an "executable specification", and now the problem becomes is the specification interpreter/compiler correct? If so, your implementation has no choice but to match the specification. The Python library Connexion implements this approach. <a href="https://connexion.readthedocs.io/en/stable/routing.html" rel="nofollow">https://connexion.readthedocs.io/en/stable/routing.html</a> you augment your spec with specific python functions. It will automatically validate all requests against the spec.<p>Another approach is template generation, where the specification becomes input to a code generation, forming the skeleton that you fill out with your code. Swagger Codegen uses this approach. There are other generators too. I haven't used them, but I'd be worried about the overhead of regeneration/specification change, and possible implementation drift.<p>At a different level entirely, you have automated testing. <a href="https://dredd.org/en/latest/index.html" rel="nofollow">https://dredd.org/en/latest/index.html</a> is a great tool for OpenAPI. It's basic behavioral testing that the implementation matches the spec. If you're using the above approaches, running such a test is kinda superfluous. <a href="https://schemathesis.readthedocs.io/en/stable/" rel="nofollow">https://schemathesis.readthedocs.io/en/stable/</a> is another cool one. If your main worry is specification drift, these tools are your friends.
Several teams at my org use Smithy.
The gist of it is that you define the spec and Smithy will generate the data model and clients.<p><a href="https://awslabs.github.io/smithy/" rel="nofollow">https://awslabs.github.io/smithy/</a>