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

On 10/22/2015 01:20 PM, Dietrich Schulten wrote:
> Hi,
> 
> Am 22.10.2015 um 07:17 schrieb Thomas Hoppe:
>> Hi Dietrich,
>>
>> Am 21.10.2015 um 19:00 schrieb Dietrich Schulten:
>>>
>>>
>>>
>>> Proposal: "the client must not make assumptions which partial view it
>>> receives as initial response, it has to rely on available navigation
>>> controls".
>>>
>> +1
>>>
>>> But this poses a question. Currently we have only the page number to
>>> qualify the current view. Somehow I want to be able to recognize that
>>> I am back at the initial page. Can the initial page be No.  0, with
>>> positive and negative page numbers? Should the PartialCollectionView
>>> have an optional title which could give a human readable string like
>>> 'Today' , 'Yesterday' , 'Tomorrow' or so - or maybe even a predicate
>>> to say exactly which range I am looking at? The latter gets
>>> complicated fast ;)
>>>
>> To get to know whether you are on the first, page, why not just look at/
>> compare with the "first" link?
> 
> Do you mean the initial view received or the first view in the series of
> views that together form the collection?
> 
> 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 :-)
> 
> We can postpone this question, it is not something that speaks against
> the hydra:view concept, especially if we do say that the client must not
> make assumptions which view it will receive initially.

+1 to moving all the exciting brainstorming to another thread and
respect this one as *call for consensus*

I only asked for few precise clarifications and based on them proposed
to include in spec *one of possible responses* from dereferencing URI
which denotes the collection itself (distinct from any of URIs which
denote various views on that collection). Possibly also including
clarifications on what client should and should not expect in response
to such very common request. Eg. in JSON representation:
1) the root element always stays the collection itself
2) it has *certain subset* of all its members included in array
appearing as value of hydra:member property
3) it has hydra:view proper which value represents a *certain view*,
directly related to which subset all members got included in the response
4) server decides which view include in request to URI which denotes
collection itself, and extensions can provide mechanisms to negotiate
with the server view which clients prefers

Received on Friday, 23 October 2015 10:01:47 UTC