ruby-grape
[WIP] Open api3 rebased
This is rebased version of the branch oapi-3 from #744
Current state:
Finished in 11.31 seconds (files took 0.94256 seconds to load)
644 examples, 34 failures, 2 pending
Finished in 7.49 seconds (files took 0.9935 seconds to load)
644 examples, 34 failures, 2 pending, 76 errors occurred outside of examples
Finished in 11.31 seconds (files took 0.94256 seconds to load)
644 examples, 34 failures, 2 pending
Finished in 11.22 seconds (files took 0.93428 seconds to load)
644 examples, 52 failures, 2 pending
The reason for 📈 🔴 is: after alignment of the openapi3 schema builder with the openapi2, the request object goes under the $ref, some specs become red.
Finished in 12.34 seconds (files took 1 second to load)
644 examples, 69 failures, 2 pending
📈 🔴 after the addition of validation against the OpenAPI3 specification.
My intermediate thoughts and Suggestions:
First of all I would like to say that @blakepettersson has done a fantastic job. I really appreciate the effort, especially the specs, which make me confident about achieving OpenAPI3 schema from Grape endpoints.
However, while working on the branch, I felt that the chosen strategy might not be ideal. Copying the existing OpenAPI2 code and modifying it for OpenAPI3 resulted in two separate codebases doing almost the same job, making synchronization difficult.
In addition, the new DryValidation and DrySchema support for request parameter definition is not currently supported in the existing code. This could be a deterrent for potential users who may choose other frameworks if Grape lacks this feature.
But there's hope. I believe that we should separate the process of gathering endpoint information from the process of schema generation, possibly by using intermediate structures. These structures can be fully populated first, and then we can generate the specific OpenAPI version schema.
One possible implementation is to use DrySchemas as schema objects that can be translated from native Grape params. This approach offers the benefits of schema composition, which is a valuable feature in OpenAPI3 that is missing in OpenAPI2.
Overall, a more modular approach could make maintenance easier and support both OpenAPI2 and OpenAPI3 more effectively.