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

Hi Karol,

>>> 1. What response body should be returned for http://api.example.com/an-issue/comments request? With "view" or without it?
>> I would say: the body of http://api.example.com/an-issue/comments?page=1
>> with a Content-Location of http://api.example.com/an-issue/comments?page=1.
> Well, that's an option. Personally I prefer to return full body as client did not state any specific view (page in this scenario).

Up to the server to decide then I'd say;
the client also didn't say it may not be paged.

>>> what defines how many items per page there is?
>> The server, like anywhere else on the Web.
> Ugh, this is all wrong. Indeed server may provide defaults, but in UI applications users may have possibility to state exactly how many items on page they want.

The latter seems to be the exception.
Few of the sites I know offer this option.
But most importantly: the current design does not say
who decided on the page size. This can thus be specified later.

>> We should verify that the proposed paging is not incompatible with it,
>> but I don't see any problems with the view-based model.
> Indeed, my concerns are only towards naming. If we're stick to paging only we may end up with terms strictly bound to that concept and I acknowledge few more cases than paging.

Paging seems a very flexible concept to me.
Any concrete cases we cannot solve with paging?

> I think inconsistencies between views when no data change is present may proove problematic for client side implementations (i.e. from performance point of view).

We should specify that paging should be consistent if the data doesn't change.
(Consistent with regard to some order.)

>> We don't need to make this work for non-RDF representations as far as I'm concerned;
>> doing so would severely limit what we can do.
> We should. Again, hydra not being able to handle non-RDF payloads will be it's nail to the coffin.

I did not say it should not handle these;
just that we not necessarily need to page non-information resources.

> There is not that much of a work needed in order to support it

Not sure that not much work is needed, and,
importantly, we might be making unnecessary compromises.

> Actually in previous conversations regarding Hydra design goals you agreed with me with these words:
> "We should think of images, video, …"

Yes. We should be able to express pages with videos in Hydra.
And this is supported with the current design.

We should not necessarily be able to page a video.

>> What aspects of paging would be necessary to detail in the API documentation?
> Well, it's more related to cardinality issues and iri templates.

Okay, but nothing paging-specific then?

Best,

Ruben

Received on Tuesday, 20 October 2015 19:55:28 UTC