Re: Call for consensus for the pagination design (ISSUE-42)

Am 22.10.2015 22:22 schrieb Karol Szczepański <karol.szczepanski@gmail.com>:
>
> Hi 
>
> Following your interesting discussion... 
>
> >I would have expected hydra:first to be the first view in the series, 
> >but following Elf, the @id of the collection can point to any page in 
> >the series, as the server chooses. In that case looking at hydra:first 
> >won't tell me if I am in the initial view. 
> >I just realized that there is no hydra:pageNo where we could say that 
> >the initial page is always no. 0 :-) 
> Actually with partitioning based i.e. on dates we cannot talk about pages! 
> These are indeed partial views but I hesistate to call it a page when the 
> view is on daily basis. 
> Still, this doesn't change the general concept of a hydra:view. 
> The question is, shall these cases with different partitioning schemes be 
> elevated to specific views? 
> Or are these just separate resources provided by the API? Consider these 
> examples: 
> http://temp.uri/api/posts?page=1 - standard paging 
> http://temp.uri/api/posts?date=2015-10-22 - should be this rised as hydra 
> view mechanism? 
> http://temp.uri/api/posts/2015-10-22 - or should it be a feature of the API 
> to be implemented by the developer 
> http://temp.uri/api/posts/2015-10-22?page=1 - this still can be paged! 
> Still, it might be worth of having something in hydra to tell client on how 
> to construct some iri templates. 

I would suggest to use hydra:IriTemplate. The url query params can be described by its mappings. 

You put hydra:search on the collection, its value is an IriTemplate. At least the situations below can be covered nicely by it. 

>I can imagine these situations: 
> http://temp.uri/api/posts?page={?page} where ?page maps to vocab:pageNo 
> http://temp.uri/api/posts/{?year}/{?month}/{?day} - where ?year, ?month and 
> ?day maps to vocab:year, vocab:month, vocab:day 
> http://temp.uri/api/posts?filter={?freetextSearch} where ?freetextSearch 
> maps to hydra:freetextSearch 
> http://temp.uri/api/posts?order-by={?property} where ?property maps to 
> vocab:property 
> This enables client to handle and combine these effectively. I hesistated to 
> put all of these into hydra, but haview few extra predicates in an extension 
> is of no use either. 

Certainly worth a thread of its own. But let us keep this out of this call for consensus for the view construct - unless it prevents a consensus for you. 

Best regards, 
Dietrich