Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No metadata fields with GET on a folderish resource #681

zopyx opened this issue Mar 3, 2019 · 2 comments · Fixed by #767


Copy link

commented Mar 3, 2019

items contains only URL and title of subresources contained with a Folder. This usually not enough for generating even minimal listings . For fetching additional metadata on a resource you need to perform individual requests for each item of items. This is inefficient.

            "@id": "",
            "@type": "Folder",
            "description": "",
            "review_state": "published",
            "title": "Nachrichten"

The @search endpoint supports the metadara_field query parameter for receiving additional metadata for all found items.

We need something similar for GET on a folderish resource in order to build efficient frontends. An application must be able to fetch all related items with all requested metadata in one API call instead using #(len(items)) additional API calls.


This comment has been minimized.

Copy link

commented Mar 8, 2019

The @search endpoint supports a fullobjects parameter:

You have the option to enhance the GET serializer to match your requirements using a more specific adapter.

I guess that it would make sense to add the fullobjects param to the GET by default, something to discuss about it.


This comment has been minimized.

Copy link
Member Author

commented Mar 9, 2019

You want to support both fullobjects and metadata_fields for the sake of API consistency. But fullobjects is not a replacement for metadata_fields because fullobjects wakes up all objects while the metadata_fields information could be determined more efficiently from the brains.

@buchi buchi added this to To do in Beethoven Sprint 2019 via automation Jun 22, 2019
@buchi buchi self-assigned this Jun 22, 2019
@buchi buchi moved this from To do to In progress in Beethoven Sprint 2019 Jun 22, 2019
@buchi buchi moved this from In progress to Done in Beethoven Sprint 2019 Jun 22, 2019
@tisto tisto closed this in #767 Jun 30, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
3 participants
You can’t perform that action at this time.