RE: Pagination (ISSUE-42)

It seems, there's quite some pushback to separate paginated collections into collections and pages. My feeling is that even getting rid of the PagedCollection type seems to be the preferred approach at the moment. This would mean that there's always a sequence of collections but if there's just one, there's obviously no need to link to others.

Let me try to gauge the preferences by making an alternative design proposal:
  - remove the type PagedCollection
  - rename itemsPerPage to numberItems
  - drop the "Page" suffix from firstPage, nextPage, previousPage, lastPage

I'm a bit worried about dropping the "Page" suffix, but wanted to bring it up nevertheless.

With this new design, a paginated collection would look like this:

  {
    "@id": "http://api.example.com/an-issue/comments?whatever=3",
    "@type": "Collection",
    "first": "/an-issue/comments",
    "previous": "/an-issue/comments?whatever=2",
    "next": "/an-issue/comments?whatever=4",
    "last": "/an-issue/comments?whatever=498",
    "member": [ ...]
  }

What we lose by this is the ability to distinguish whether a single "page" or the complete collection was referenced. It would always be the complete collection. A client is thus expected to (potentially) retrieve the entire collection to find the information it was looking for. AFAICT, this shouldn't be a problem in practice as our collection design doesn't allow any inferences; all the relationships have to be defined explicitly.

Ruben, I would be especially interested in hearing your opinion since you created ISSUE-42 [1] and mentioned that by implementing the LDF server it occurred to you that the current design is confusing. Do you see any practical issues with such a design?


--
Markus Lanthaler
@markuslanthaler

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