Feature: Filtering of endpoints and tags

[kirides]

This PR demonstrates how #131 could be implemented

It add --match-path and --tag CLI options, which allow the user to filter endpoints based on existing Tags and/or if the Path matches an regular expression.

It's not as fine grained as for supporting HTTP methods. I.e. you can't filter for ^/greet and only allow GET and PUT or something like that.

A call might look like this:

refitter.exe swagger.json --tag Greeting --tag OpenApi --match-path '^/api/'

It works by modifying the OpenApiDocument and removing the Paths/Methods that don't match any of the Tags or patterns, thus further steps in code generation only see the filtered document.

[codecov]

Codecov Report

Merging #132 (4529cd5) into main (a074908) will increase coverage by 0.15%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #132      +/-   ##
==========================================
+ Coverage   98.29%   98.44%   +0.15%     
==========================================
  Files          32       34       +2     
  Lines         997     1094      +97     
==========================================
+ Hits          980     1077      +97     
  Misses          6        6              
  Partials       11       11              

Flag	Coverage Δ
unittests	98.44% <100.00%> (+0.15%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Changed	Coverage Δ
src/Refitter.Core/RefitGenerator.cs	100.00% <100.00%> (ø)
src/Refitter.Tests/Examples/FilterByPathTests.cs	100.00% <100.00%> (ø)
src/Refitter.Tests/Examples/FilterByTagsTests.cs	100.00% <100.00%> (ø)

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
4 Code Smells

No Coverage information
0.0% Duplication

[christianhelle]

I really like this approach. It seems so much more simple to just trim the OpenAPI document down instead of checking every single endpoint upon generation

[christianhelle]

The changes here looks good to me. Shall we merge this in @kirides? Or do you have pending changes?

[kirides]

I would still have to check if the source generator works and maybe clean up the filtering mechanisms.

Also need to take a look at poco generation, maybe there's room for improvement (remove unneeded schema from document after filtering it)

[christianhelle]

I would still have to check if the source generator works and maybe clean up the filtering mechanisms.

Thanks for thinking about that @kirides

Also need to take a look at poco generation, maybe there's room for improvement (remove unneeded schema from document after filtering it)

It might be dangerous to tamper with the contracts. We need to make sure that the contract types that we skip generating are not referenced by other contract types

[kirides]

@christianhelle after evaluating my consideration about trimming contracts, i came to the conclusion that there is no way to get it right, due to the spec allowing for additional schema and things like "any object" as result or parameters.

if the code looks good for you, and the checks are green we can merge it :)