RE: Pagination (ISSUE-42)

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.


> 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?


> 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.



--
Markus Lanthaler
@markuslanthaler

Received on Thursday, 12 February 2015 22:18:44 UTC