UrlFor fields include all passed params in url.

[tinproject]

UrlFor fields use all the passed parameters of the field in construct the url, this makes those fields unsuitable to use with apispec in the same way as other marshmallow fields, or with any information at all.

Example:

    image_url = URLFor(
        endpoint='return_image_file',
        id='<id>',
        required=True,
        description='url location of the image file.',
    )

Result:

"image_url": "/api/image/191.png?description=url+location+of+the+image+file.&required=True",

Perhaps the best way to avoid this is define a new argument in the fields: endpoint_params, for example, to store a dict with all the endpoint parameters. For backward compatibility it can look for the existence of that argument and if exists use the parameters of the dict inside, if not use the parameters of the field as is currently done.

[dhofstetter]

Totally agree with that ...

Is there a special reason for this behaviour?

[sloria]

I agree that the current behavior isn't ideal. I would certainly review and merge a PR fixing this. I like @tinproject 's idea of using a different argument to specify url_for arguments. Perhaps it should be named values for consistency with the url_for API.

[dhofstetter]

Something like that I actually used now within my project, just inherited the existing fields and adding a dict parameter that takes all the arguments for url_for.

That is good so far, and now I'm perfectly fine with defining all the stuff I need to document my stuff as expected without getting this weird params within the url.

[AlrasheedA]

A temporary solution that I followed was using "post_dump" decorator to remove the params. Not an ideal solution but gets the job done. @sloria can you share the relevant PR

[alexschoeberl]

Any updates on this issue?

[sloria]

No updates from me. I won't have time to work on this myself in the near future, but I would review and merge a PR implementing the behavior described above.