feat: implements openapi to scanapi.yaml convertion#866
feat: implements openapi to scanapi.yaml convertion#866guites wants to merge 38 commits intoscanapi:mainfrom
Conversation
this could happen if the same path has multiple methods without summary/operationId
|
Hey :) I think the code reached its final form. I'm marking it as ready for commit, but I'll still add tests for the |
|
This looks such a good feature. Let me review this. 🚀 |
do not instantiate third party libraries inside the class responsible for convertion logic, this facilitates if we ever need to change dependencies (we only need the parsed schema as a python dictionary). add a new validation layer for invalid yaml and broken openapi schemas move printing to the intermediate layer (convertion module shouldn't be responsible for communicating information to the user)
|
I've finished implementing the test suite :) Now there are some issues from DeepSource, but I'll leave it as is for now and fix them based on what is discussed |
|
I've fixed most of deepsource problems and ignored all documentation/formatting related issues (see https://app.deepsource.com/gh/scanapi/scanapi/run/0ae4f501-371d-478b-b552-235b85f2473f/python/). I think we can go ahead and skip deepsource output altogether for this PR. |
|
Our convertion pipeline is based on prance (https://github.com/RonnyPfannschmidt/prance) using the openapi-spec-validator backend (https://github.com/p1c2u/openapi-spec-validator). The default behavior is to block parsing of schemas with non-compliant fields. For example the following schema (the "example" field is defined incorrectly under a response definition. see https://spec.openapis.org/oas/v3.1.0#response-object) : Would result in the following error (when running
The specific error (in this case If we change version 3.0.4 to 3.1.0, keeping the same schema, we get the following error:
The error changed to I think it's pretty common for OpenAPI specs to have incorrect/incompatible fields, since there are so many spec generation tools out there. cc @camilamaia wdyt? Should we move forward with a "strict" implementation for now and study having a prance seems to accept a edit: the |
Description
Implements a OpenAPI specification to ScanAPI.yaml convertion.
Motivation behind this PR?
Increasing ScanAPI adoption by reducing friction is a long going issue (see #814).
This PR attempts to provide a sample script that converts OpenAPI v3 files, which are very popular, into a scanapi.yaml file.
The objective is to give project maintainers a starting point into implementation ScanAPI to their pipelines.
I'm referring to this starting scanapi.yaml file as a skeleton file. The skeleton should include (by running the convertion script once):
Benefits to this approach:
Some downsides:
Example usage
Let's take the Futurama API project as an example. It's swagger documentation can be accessed here: https://futuramaapi.com/swagger#/ .
We can download the OpenAPI spec file (from https://futuramaapi.com/openapi.json) and run the following command:
This would result in the following ScanAPI yaml:
Points of interest:
headersentry withAuthorization: Bearer ${bearer_token}. If we defined thebearer_tokenanywhere on the file, we have working authentication for these endpoints./api/characters/${Character_character_id}) have the path parameter as a variable. This means we can quickly implement this variable in another endpoint.What type of change is this?
Implementation of a new feature.
Checklist
Issue
Closes #<issue_number>