- From: Ruben Verborgh <ruben.verborgh@ugent.be>
- Date: Tue, 3 Feb 2015 19:14:32 +0100
- To: Gregg Kellogg <gregg@greggkellogg.net>
- Cc: Tomasz Pluskiewicz <tomasz@t-code.pl>, public-hydra@w3.org
> Again, IMO, separate Page and Collection types is probably going too far > Each Collection resource provides first/last/previous/next links, as well as itemsPerPage/totalItems. The above statements seem mutually exclusive to me: the previous and next relationships should be functional, but if they are attached to the collection, they are not. If they are attached to the page, then the page is a separate type. Concretely, we can't meaningfully have: </collection> :nextPage </collection/page/2> and </collection> :nextPage </collection/page/3> at the same time. We can have </collection/page/1> :nextPage </collection/page/2> and </collection/page/2> :nextPage </collection/page/3> and then we can still choose whether we attach :firstPage and :lastPage to the collection or a page. > We also don't need to mandate what query parameters are used, and could simply be "?page="; why should a client care? It's entirely determined by the collection metadata. Exactly. Note that :nextPage could even be "?offset=200&limit=100"; so even if the API supports offset/limit, we can still do simple paging. This approach is currently taken in http://data.kbodata.be/fragments. Best, Ruben
Received on Tuesday, 3 February 2015 18:15:07 UTC