For a while, the whole world was trying to move over from REST to GraphQL. Frontend developers loved it because they could get exactly what they wanted. However, implementing a backend for it is a lot of work. So, when I saw a blog post criticizing GraphQL, it resonated with me.
REST is simple and easy to use. However, maintaining the REST schema is always involved.
Here’s where the Open API specification comes in. It adds a layer of objects to define the RESTful API.
For internal usage, I think you should start with a server first.
Let’s consider a simple example in Python.
| |
Run the file with python -m fastapi dev simple_web_server.py and then see the specification at
http://127.0.0.1:8000/openapi.json.
You can also see the documentation at
http://127.0.0.1:8000/docs.
One can use an online service like readme.io to generate documentation from the specification. Or one can use the API specification to generate the client code.
Let’s say you want to generate the Go client code.
| |
You can then use the client code to make the API calls.
| |
Commit Open API specification to version control
I would highly recommend against committing the generated code to a version control though.
This way, you can add a vacuum linter to ensure that the specification does not have any errors or lint issues.
Further, use oasdiff in your version control to prevent any breaking changes to the API.
You can use gabo to auto-generate the GitHub Actions to lint, validate, and prevent breaking changes to the Open API specification.