- From: Tomasz Pluskiewicz <tomasz@t-code.pl>
- Date: Tue, 03 Feb 2015 16:56:20 +0100
- To: public-hydra@w3.org
On 2015-02-03 16:31, Ruben Verborgh wrote:
> Hi Andrew,
>
>> In my api's and clients I much prefer to use offset and limit as a more fundamental concept to partial collections.
>
> This has strong repercussions of the cacheability of answers,
> which is crucial when many clients consume the API.
> (Graphs: http://linkeddatafragments.org/publications/iswc2014.pdf)
>
I've also disliked limit/offset endpoints because they empower users to
query for very large portions of data unless the limit parameter is
constrained.
>> Offset and limit is also how SQL databases tend to handle these things
>
> But we shouldn't make any assumptions on the underlying datasource.
>
> I'm not against limit/offset per se, but we definitely first support a more simple interface.
>
But what is there to support in terms of limit/offset, really? I mean it
is already possible to define a templated link and make the limit and
offset as variables. So it is possible to define a templated link to nth
page. And indeed dynamically calculated pages are likely to use limit
and offset underneath anyway. Also, on the other hand limit and offset
can easily be used with the proposed firstPage, nextPage etc, assuming
some predefined page size.
{
"@id": "/collection?limit=10&offset=10",
"@type": "Page",
"pageOf: {
"@id": "/collection",
"nextPage": "/collection?limit=10&offset=20",
"previousPage": "/collection?limit=10",
"search": {
"template": "/collection{?limit,offset}"
}
}
}
Bottom line is we may want to define property to replace hydra:search
bove. All the other building blocks are in place and how we address our
pages is irrelevant IMO.
>
> Best,
>
> Ruben
>
Received on Tuesday, 3 February 2015 15:57:21 UTC