marshmallow-code / marshmallow-code/flask-smorest
Are query based blueprint arguments after path arguments formally unsupported?
- Dominant language
- Python
- Stars
- 717
- Forks
- 77
- Avg merge
- 7h 49m
- Merged PRs (30d)
- 3
Description
As an example (modified from the documentation sample code):
```py
class PetSchema(ma.Schema):
id = ma.fields.Int(dump_only=True)
name = ma.fields.String()
class PetQueryArgsSchema(ma.Schema):
name = ma.fields.String(required=False)
blp = Blueprint(
"pets", "pets", url_prefix="/pets", description="Operations on pets"
)
@blp.route("/")
class PetsById(MethodView):
@blp.arguments(PetQueryArgsSchema, location="query")
@blp.response(200, PetSchema)
def get(self, pet_id, query_args):
ps = PetSchema()
ps.id = 1
ps.name = f"pet_id: {pet_id}, query_args: {query_args}"
return ps
```
Intuitively, I would expect the PetsById.get method to populate with the pet_id as the first positional argument, followed by the query_args as a dictionary. It turns out it doesn't really work like this. In fact, it doesn't really work at all. This produces a TypeError as a result of mulitple arguments for 'pet_id'.
I found these other discussions: #219, #220, related to this issue, but I'm not sure if there were any conclusions drawn as to what the behavior here should, ideally, look like. For some context, my interest is in constructing an endpoint with a mandatory path argument, but a set of optional filtering values passed in the query. That behavior does not appear to be supported by blueprint argument decorators, however. That said, I suppose I'm ultimately asking is this either, 1) a bug in how flask-smorest handles these argument combinations, or 2) simply an unsupported feature that could perhaps be clarified by updates to the documentation?
Contributor guide
Research direction
Start by reproducing the documented PetSchema, PetQueryArgsSchema, PetsById, and get example, then review the related discussions in #219 and #220. Determine whether path and query blueprint arguments are intended to work together; done means the supported behavior is either clarified in the documentation or corrected with the example no longer raising the reported TypeError.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- flask, openapi, python
- Domain
- api
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100