Re: totalItems with pagination and filtering

Hi

>>>> I would turn this around. Where does /users go when the @id is
>>>> /users?name=Bob? How about sth like that
>>>>
>>>> GET /users?name=Bob&p=1
>>>> {
>>>>    "@id": "/users?name=Bob",
>>>>    "partOf": "/users"
>>>>    "@type": "Collection",
>>>>    "member": [ ...10 Bob items... ],
>>>>    "totalItems": 50,
>>>>    "view": { .. the page links ... }
>>>> }
>I think the main to keep in mind thing here is that there's only one 
>collection resource and we are trying to describe various views of that 
>resource. As such, we could model it as follows
Agree - it's a collection with it's views.

>I don't think we should support a hierarchy of view.
Agree again - while from user point of view additional parameters attached 
to query here may create an impression of a view hierarchy, but I think view 
is a, well, a view. Union of all possible views should give a complete 
collection.

>An alternative would be to allow to attach totalItems to 
>PartialCollectionView in case it differs from the underlying collection:
>  {
>    "@id": "/users",
>    "@type": "Collection",
>    "member": [ ...10 Bob items... ],
>    "totalItems": 10000,
>    "view":
>      "@id": "/users?name=Bob&p=1",
>      "@type": "PartialCollectionView",
>      "totalItems": 50,
>      "first": "/users?name=Bob&p=1",
>      "next": "/users?name=Bob&p=2",
>      "last": "/users?name=Bob&p=5"
>    }
>  }
>... which looks much simpler but may be conceptually ambiguous.
This ambiguoity comes from a collection and it's view representation, not 
the opposite. Finally we'll need totalItems for both as attaching it only 
the collection and still having a view is somehow unnatural.

>>>> My idea would be to always use the parametrized @id (so that you can
>>>> bookmark it) and add a link to the unfiltered collection, here
>>>> "partOf" as an example.
>>>
>>> After I sent the email I had the same thoughts and I agree, it makes
>>> more sense to browse through the filtered collection, especially because
>>> totalItems works then. I also thought about how to link to the
>>> unfiltered collection, that's tricky.
>I think both are valid but the main question is we want to treat the 
>filtered view as a separate collection or not.
Well, view of a collection is still a collection - but this would imply a 
view hierarchy which is not good. Anyway, I'm not sure where is the problem 
here. There is nothing against a server to return this to GET 
/users?name=Bob&p=1:
{
"@id": "/users",
"@type": "Collection",
"member": [ ...10 Bob items... ],
"totalItems": 50,
"view": {
  "@id": "/users?name=Bob&p=1",
  "@type": "PartialCollectionView",
  "first": "/users?name=Bob&p=1",
  "next": "/users?name=Bob&p=2",
  "last": "/users?name=Bob&p=5"
}
}
while for GET /users it would return just return this:
{
"@id": "/users",
"@type": "Collection",
"member": [ ...all items... ],
"totalItems": 10000
}

>> To complete this train of thought, I would point out that this is how
>> this works in HTML. You normally see a summary similar to "displaying 10
>> out of 50 items" and that total number usually (always?) means the
>> number of filtered results.
>Right, you typically get the total number of items of the filtered view but 
>not the total number of items of the complete collection.
Agree - this is how I acknowledge this value in my POC client as well - 
total number of items in the current "view configuration" (page, filters, 
etc.).

>>> To help think about it, let's imagine we subclass Collection and use
>>> something like FilteredCollection which could then include some custom
>>> predicates like "appliedFilter": {"name": "Bob"}, and the link to the
>>> unfiltered collection which should be unambiguous.
>How would a FilteredCollection differ from a PartialCollectionView?
I think this is is due to a "unlucky" PartialCollectionView name. 
PartialCollectionView is a view already, but it's name suggests it's only 
for pages. I think I suggested something more generic like PartialView - 
this would avoid such situations.

>> Your idea seems sound. I'd have to defer that to other on this list for
>> detailed discussion. My thought is that the "appliedFilter" is
>> essentially an instance of a IriTemplate with variables filled in. I
>> would model it with the IriTemplate in mind.
We somehow start to have this discussion in several places (Ruben's 
hydra:filter not to look to far). Maybe it's worth of starting a separate 
discussion on whether we want anything other than paging in the core or not 
and if we want, how should we approach filtering or in general view 
crafting?

Best

Karol

Received on Thursday, 26 November 2015 21:25:31 UTC