Method/route combinations appear in swagger documentation output that are not in the code

[JasonWWalton]

Permutations of routes and methods appear as documented operations in the swagger output that aren't present in the code. Other applications rely on the JSON output of swagger, and the superfluity of operations breaks that.

mod.add_url_rule('/edges/', defaults={'annotation_id': None}, methods=['GET']) mod.add_url_rule('/edges/', methods=['POST']) mod.add_url_rule('/edges/<int:annotation_id>/', methods=['GET', 'PUT', 'PATCH', 'DELETE'])

i.e. The code defines a route at /edges/ with "GET" and "POST" methods. The code also defines a route at /edges/<int:annotation_id>/ with "GET", "PUT", "PATCH", and "DELETE" methods. [This is a total of 2 routes and 5 method verbs.] The swagger output shows a list of 10 operations, which includes combinations of verbs and routes that don't exist in code (e.g. "POST" for the /edges/<int:annotation_id>/ route, and "PUT" for the /edges/ route).

[atlithorn]

Thanks for the bug report Jason. I'm currently on vacation with limited internet access. I'll have a look as soon as I can.

Atli

On Monday, June 15, 2015, Jason Walton notifications@github.com wrote:

Permutations of routes and verbs appear as documented operations in the swagger output that aren't present in the code. Other applications rely on the JSON output of swagger, and the superfluity

E.g. The code defines a route at "/edges/" with "GET" and "POST" methods. The code also defines a route at "/edges/int:annotation_id/" with "GET", "PUT", "PATCH", and "DELETE" methods. [This is a total of 2 routes and 5 method verbs.] The swagger output shows a list of 10 operations, which includes combinations of verbs and routes that don't exist in code (e.g. "POST" for the "/edges/int:annotation_id/" route).

— Reply to this email directly or view it on GitHub https://github.com/gangverk/flask-swagger/issues/10.

[JasonWWalton]

Thanks for responding. Hope your vacation is a nice One.

[ibratoev]

@JasonWWalton, can you test if #11 is a fix for this issue?

[atlithorn]

Jason, could you provide a little test script (similar to example.py in the repo) so I can reproduce this and figure out what's going on? I have seen @ibratoev's solution and it looks good but I want to reproduce this for myself before merging the code and I have been unable to do so via the description in your bug report.

[ibratoev]

To reproduce that you can change this from the current example:

app.add_url_rule('/users/<int:team_id>', view_func=UserAPI.as_view('users'))

to

app.add_url_rule('/users/<int:team_id>', view_func=view, methods=["GET"])
app.add_url_rule('/testing/<int:team_id>', view_func=view)

I expect only the GET to be described for the /users/* url but both GET and PUT are. I can suggest adding a few testing tests to cover the existing functionality. I can help with that if you wish when I get some free time.

[atlithorn]

Yes that's a good idea @ibratoev and would be highly appreciated.

I see how your PR will fix this problem and I'm going to merge it now, I would however be interested to hear from @JasonWWalton as well, hopefully this solves his problem

[JasonWWalton]

Gentlemen, this does appear to solve my problem! Thanks for taking a look. My apologies if the description I provided did not clarify the issue. But I'm glad you were able to get to the bottom of it. And glad the fix helps others as well. Thanks again. In the meantime I had resorted to creating another class for the endpoints that take an argument in the path. But this could be cleaner.