I would say yes, but I would also not want to change the current API version to do this, because it will break thousands of plugins, and that's not how you build APIs.
So either:

1. a new version that is based on the OpenAPI spec
2. A flag/parameter/http header that can be set to change to the OpenAPI spec

I absolutely agree with you that introducing OpenAPI shouldn't be a breaking change.

I think the first step should be introducing the OpenAPI spec only as a manner of documentation of the existing APIs, without replacing anything in the current infrastructure that serves the APIs, nor modifying the APIs themselves.
The specification should be fully built (and possibly tested against current tests) before even thinking about using it to introduce breaking changes.

Hi @NiccoMlt

Does it make sense documenting our current V2 API with OpenAPI? (Even though we are not OpenAPI compliant?) I don't know how OpenAPI works, sry :)

Does OpenAPI provide a tool that builds documentation upon an existing API/schema? If so we can try it out and see the kind of documentation it generates.

Hi @Naramsim, I'll answer in points:

Does it make sense documenting our current V2 API with OpenAPI?

Yes, I think so: for example, it would help with code generation for clients, servers and tests, which I think is good enough 😄.

Even though we are not OpenAPI compliant?

OpenAPI isn't heavily opinionated, so I don't think PokéAPI is using something undocumentable; I may be wrong tho, I discovered PokéAPI not so much ago, so I don't know the APIs very well...

Does OpenAPI provide a tool that builds documentation upon an existing API/schema?

OpenAPI by itself is only a specification, and it's commonly used in two opposite approaches:

• Design-first, in which the OpenAPI spec is used with some build tool to generate the server code for the documented API, along with model classes and tests;
• Code-first, in which an OpenAPI spec is generated either build-time or run-time from the API defined on a server in the traditional way.

I prefer the first approach, because I think it is much more clear and maintainable, but to try to use OpenAPI with PokéAPI we could use the second approach to have something to start from.

This repo uses a Django server to serve the APIs; I don't know Python at all, so I may be missing something, but after some researches I can say that there are still no django plugins/middleware/whatever that could be plugged to have a code-first OpenAPI spec generation.

Do you know any PokéAPI servers written with some other framework (ASP.NET Core, most modern JVM-based frameworks and nearly all the JS-based frameworks support OpenAPI)?

Actually we use Django REST Framework, which does have some OpenAPI support in the form of plugins:

https://www.django-rest-framework.org/api-guide/schemas/#generating-an-openapi-schema

The actual API you're consuming on the web isn't hosted on Django, but that's neither here nor there for generating the docs.

Actually we use Django REST Framework, which does have some OpenAPI support in the form of plugins

That's great!
This plugin should be able to be used to generate a valid specification to test the ground and potentially start from!

What do you think?

Hi, I tried generating the static schema using the first suggestion from your link using the environment deployed on Docker with the Docker-Compose you bundle; I put the result on this Gist: https://gist.github.com/NiccoMlt/073b18934a6001fc5a2414c590e3b8ba

Currently the spec is not valid (apparently, pyyaml doesn't resolve the tuples correctly?) but it is a starting point.

I think that would be an awesome addition, now that code generation is getting more and more popular be able to create clients to consume this api without having to write "contract" logic would be amazing !!!

@NiccoMlt Thanks for the static schema, I used that as a baseline spec (and made it valid manually) for generating API clients using openapi-generator https://github.com/cliffano/pokeapi-clients .

The main gap at the moment is that the response payload is just strings at this stage. As I'm not familiar with the Python codebase, can anyone suggest how to to best identify the payload model for the endpoint responses? My intention is to convert the model into OpenAPI schema.

@Naramsim Here's an example of the generated doc https://cliffano.github.io/pokeapi-clients/api/latest/ using bootprint-openapi.

This could be an option tfranzel/drf-spectacular