Skip to content
This repository has been archived by the owner on Jun 6, 2024. It is now read-only.

self_url_many should have a self_url_many_kwargs #275

Open
fhriley opened this issue Dec 5, 2019 · 3 comments
Open

self_url_many should have a self_url_many_kwargs #275

fhriley opened this issue Dec 5, 2019 · 3 comments

Comments

@fhriley
Copy link

fhriley commented Dec 5, 2019

self_url_many in a schema's Meta class should have a corresponding self_url_many_kwargs. Consider the following scenario where bars cannot exist on their own, only within foos:

class Meta:
    type_ = "bars"
    self_url = "/foos/{foo_id}/bars/{bar_id}"
    self_url_kwargs = {"foo_id": "<foo_id>, "bar_id": "<id>"}
    self_url_many = "/foos/{foo_id}/bars"

This situation is currently impossible because there is no self_url_many_kwargs.

@multimeric
Copy link

Agreed. The spec says "self: the link that generated the current response document.", so it strongly implies that any response, including a resource that has to be in a relationship, should be able to have the current URL as a self link.

@pguyot
Copy link

pguyot commented Dec 28, 2020

self_url_kwargs substitutes url with values from self (item). Where would we get the values in the case of a list with self_url_many_kwargs (foo_id in your example), including when no data is returned (the list is empty)?

@judgeaxl
Copy link

That is a good question. Additionally, even if the collection has data, which one would you pick the value from?

self_url_kwargs substitutes url with values from self (item). Where would we get the values in the case of a list with self_url_many_kwargs (foo_id in your example), including when no data is returned (the list is empty)?

I've not used marshmallow enough to say if it makes sense to pass these args to dump() or not, but as it stands the only option seem to be to dump and update, which doesn't work when dumping takes place in a wrapper, like in flask-smorest.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants