Skip to content

Conversation

@andmatei
Copy link
Collaborator

@andmatei andmatei commented Dec 18, 2025

Proposed changes

This PR adds a new slice command to the foascli that enables users to slice/filter OpenAPI specifications by operation IDs, tags, or path patterns. This feature allows developers to create smaller, focused OpenAPI specs containing only the endpoints they need

Example usage:

# Extract only Alerts endpoints by tag
foascli slice -s openapi/.raw/v2.yaml -o alerts-only.yaml --tags Alerts

# Extract specific operations
foascli slice -s spec.yaml -o output.yaml --operation-ids "getUser,createUser"

# Extract by path pattern
foascli slice -s spec.yaml -o output.yaml --paths "/api/v1/users"

Jira ticket: CLOUDP-365849

Checklist

  • I have signed the MongoDB CLA
  • I have added tests that prove my fix is effective or that my feature works

Changes to Spectral

  • I have read the README file for Spectral Updates

Further comments

…ation IDs, and paths

- Add new 'extract' CLI command to slice OpenAPI specifications
- Support filtering by operation IDs, tags, and path patterns
- Implement SliceFilter with comprehensive test coverage
- Use Cobra's StringSliceVar for cleaner flag handling
- Include all referenced schemas and components in output
- Add validation for input parameters and output formats
- Support both YAML and JSON output formats
- Update command name from 'extract' to 'slice' for consistency
- Update all examples and documentation to use 'slice'
- All tests still pass
- Fix perfsprint linter error
- Use errors.New instead of fmt.Errorf when no formatting is needed
- Add errors import
- Replace fmt.Errorf with errors.New for non-formatted errors (perfsprint)
- Fix receiver naming consistency in SliceFilter.matches method (revive)
- Change receiver name from 'e' to 'f' to match other methods
@andmatei andmatei changed the title feat: add slice command to filter OpenAPI specs feat(foascli): add slice command to filter OpenAPI specs Dec 19, 2025
- Add ParametersFilter to remove unused parameters from OpenAPI specs
- Add comprehensive tests for ParametersFilter (7 test scenarios)
- Move slice functionality from filter package to dedicated slice package
- Update FiltersToCleanupRefs to include TagsFilter, ParametersFilter, and SchemasFilter
- Fix linting issues (import shadowing and missing period in comment)
- Slice command now cleans up unused tags, parameters, and schemas automatically
@andmatei andmatei changed the title feat(foascli): add slice command to filter OpenAPI specs feat: add slice command to filter OpenAPI specs Dec 19, 2025
@andmatei andmatei marked this pull request as ready for review December 19, 2025 09:47
@andmatei andmatei requested a review from a team as a code owner December 19, 2025 09:47
Version: "1.0",
},
Paths: openapi3.NewPaths(openapi3.WithPath("/test/{id}", &openapi3.PathItem{
Parameters: openapi3.Parameters{
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you help me to understand the equivalent of this Parameters field under PathItem in the OpenAPI spec?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or, would it make more sense under Get operation?

Copy link
Collaborator Author

@andmatei andmatei Dec 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Of course, so in this example the path is /test/{id} so the path parameter would refer to id and the type it references. All parameters types are under components.parameter in the OpenAPI spec with refer to path and query parameters. Since this is a parameter for the endpoint path, it is not associated with an operation (i.e. GET, UPDATE etc.) Let me know if this clarifies everything!

Copy link
Collaborator

@yelizhenden-mdb yelizhenden-mdb Dec 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In our MMS OpenAPI spec we currently don’t use parameters in a way that applies to all operations under an endpoint. To stay consistent, it may be better to follow the same structure we already use

Based on the example, I would normally expect something like this to exist:

/test/{id}:
  parameters:
    - name: id
      in: path
      required: true
      schema:
        type: string
  get:
    …

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh yes I see that now, thank you for clarifying, will update the test cases for this!

// Check if the path matches (with normalization)
normalizedPath := normalizePath(path)
for _, pattern := range criteria.Paths {
if normalizedPath == normalizePath(pattern) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[q] does the path mtaches nested resources? ie, if I provide --filterPath atlas/api/v2, will the slice command return an openapi spec with all the resources?

Copy link
Collaborator Author

@andmatei andmatei Dec 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For this PR, endpoint paths that match exactly will be selected in the output spec. I can add in a follow-up PR support for regex path matching

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no, there is no need to add the logic if you won't use it. Just makes sure to include this clarification in the command or flag description

Comment on lines +39 to +41
if f.oas.Components == nil || f.oas.Components.Schemas == nil {
return nil
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in which scenario we have components or components.schemas nil? Note that when we load the spec with the openapi repo, we are also performing a validation that all the references in the endpoints are correctly in the component section

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was thinking for the scenarios where all the response / request bodies are inline for each API endpoint, in that case the Schemas could contain nothing

@andmatei andmatei merged commit 76e8db4 into main Dec 22, 2025
11 checks passed
@andmatei andmatei deleted the feature/add-slice-command branch December 22, 2025 17:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants