Currently, the "/collections/{node_id}/counts" endpoint returns a flat list of the subtree nodes of the queried parent collection. This means, that the frontend, would have to somehow rebuild the tree from this flat list.
On the other hand, the "/collections/{node_id}/tree" Endpoint returns the tree in a much more structured way.
IMHO, It would be nice, if the "/collections/{node_id}/counts" endpoint would also return a tree structure.
E.g. the following could do
class MaterialCountsNode:
titlle: str # the title/name of the collection
id: uuid.UUID
children: list[MaterialCountsNode]
total: int
oer: int
Eventually, the total and oer integer counts could/should then correspond to the number of materials, that are exactly in that collection.
This is particularly true, because the frontend uses some complex inheritance model and filtering to map the responses from "/collections/{node_id}/counts" back onto the CollectionNode response model of the "/collections/{node_id}/tree" endpoint!
Currently, the
"/collections/{node_id}/counts"
endpoint returns a flat list of the subtree nodes of the queried parent collection. This means, that the frontend, would have to somehow rebuild the tree from this flat list.On the other hand, the
"/collections/{node_id}/tree"
Endpoint returns the tree in a much more structured way.IMHO, It would be nice, if the
"/collections/{node_id}/counts"
endpoint would also return a tree structure.E.g. the following could do
Eventually, the total and oer integer counts could/should then correspond to the number of materials, that are exactly in that collection.
This is particularly true, because the frontend uses some complex inheritance model and filtering to map the responses from
"/collections/{node_id}/counts"
back onto theCollectionNode
response model of the"/collections/{node_id}/tree"
endpoint!