Re: Pagination (ISSUE-42)

On 2015-02-12 23:18, Markus Lanthaler wrote:
> On 10 Feb 2015 at 17:01, Tomasz Pluskiewicz wrote:
>> February 4 2015 9:34 AM, "Markus Lanthaler" <markus.lanthaler@gmx.net> wrote:
>>>
>>> It is the most basic form. The only way to achieve interoperability is
>>> to define some controls. We may end up having just those basic controls
>>> or we may end up supporting also more sophisticated ones.. but we
>>> definitely need some to be able to create interoperable clients/servers.
>>
>> I'm on the fence about this. I'm moderately convinced that defining
>> these controls as part of Hydra core is not a good idea. If
>> anything, they should be in a separate spec IMO.
>
> What would the advantage of doing so be? I'm kind of coming to the opposite view.. I think we should have thought more about splitting Hydra into a core namespace and other to-be-defined namespaces. We might still want to describe different concepts in different specifications but having a simple namespace, JSON-LD context etc. would probably simplify things down the road.
>

I see. Maybe you're right and separate namespace is enough. By all means 
I don't mean specifications as W3C means it (with all the 
standardization process and all).

>
>> Though I still
>> don't understand why the next/previous is required in the first
>> place. Interoperability be achieved simply by using the API
>> documentation, so couldn't that approach be encouraged? After all
>> that's what hypermedia controls are for. Each API could define their
>> own way for navigating between pages and they should work with any
>> compliant client.
>
> Do you realize that you just stated what the problem is? :-)
>
>     Each API could define their *own* way for navigating between pages
>
> A Hydra-conformant client is expected to know what a Collection is, what an IriTemplate is, etc. It can't be expected that such a client knows anything else. So, how would it be able to understand the way navigating between pages work in an arbitrary API if it isn't defined in Hydra?
>

Actually I think Hydra could even get away without defining Collections, 
however I see the benefit for clients to understand that a given Page is 
part of a collection.

However you miss my point about navigation. Hydra has all that is 
needed: Links and IriTemplates to point from one resource to another. It 
should not be important to the client what the actual properties are. 
Isn't that what hypermedia is about? Self-descriptive messages?

My concern is that when we start adding specialized properties for 
next/prev, offset/limit in the core spec, clients (and libraries) will 
have those hardcoded. This means that whenever a new collection 
navigation is added, clients need to be updated. Otherwise they will not 
understand the responses. It is in fact introducing out-of-band 
information of sorts.

As middle ground I like the pagination object. This could help clients 
understand that a given resource part of something bigger but leave the 
actual linking up to the API. And interoperability is not hindered IMO.

>
>> Bottom line is I wouldn't like to have all different ways for
>> pagination in Hydra core.
>
> That's an entirely different discussion IMO. Here we are only discussing the most basic form of pagination. We can then, at a later stage, decide whether we define other mechanisms and where we put them.
>
>
>> I think that it attempts to achieve too
>> much and will only force more complicated clients, which will have
>> to check for many specialized properties.
>
> Sure, it increases complexity but it also increases functionality. I regard pagination of collection as a crucial feature and thus I would like to see that supported by Hydra out of the box. The reason I see it as crucial is simply because most (to not say almost all) Web APIs need such a functionality.
>

Please don't get me wrong. I agree about pagination. What I don't agree 
is strictly defined navigation. I think that should be left for specific 
API publisher to decide.

>
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>
>
>

Received on Sunday, 15 February 2015 12:07:54 UTC