[WIP] Open api3 rebased #928
Conversation
numbata
force-pushed
the
open-api3-rebased
branch
from
290b700
to
9b6cb2a
Compare
|
👀 Looking forward to this! |
…eaner Add ApiClassDefinitionCleaner module to track and remove classes that inherit from Grape::API. This change prevents classname collisions between different specs, ensures that no remaining classes interfere with subsequent tests, and prevents ArgumentError caused by unexpected module inclusions. Details: - Created ApiClassDefinitionCleaner module with before(:all) and after(:all) hooks. - Hooks track initial and current state of Grape::API subclasses. - Identifies and removes newly defined classes after each spec run to prevent unintentional changes and conflicts.
|
|
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. |
📈 🔴 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. |
This is rebased version of the branch oapi-3 from #744
Current state: