Re: Pagination of non-collections

Tomasz,

I think you're on the right track.

As you have touched on, people have friends, hobbies, projects, family,
music, bank accounts, orders, invoices, photos, etc.  A json client often
wants this information included/excluded based on context whether or not it
is considered a property of the resource or a link to a related resource.
This is why I am wanting the related/auxilary resource handling as a first
class concept in hydra. collections/pages/ranges just evaporate as an
aspect of filtering and ordering.

Consdier a use case, a collection of posts, which have a related author and
comments.  A client wants to show a list of recent unread posts, up to say
25 because thats all that will fit in the viewport, but the client only
wants the date, title, author name, author avatar, comment count, vote
count.  When expanding a post, the client now wants the post body and
perhaps the comments with score 3-5, but only the first 10.  Infinite
scrolling is used for both posts and comments, and assume the client screen
orientation can be rotated, affecting the optimal page size requirement in
a heartbeat. When reading the posts, I want the user to be able to bulk
flag those posts they have read, meaning I want to be able to
operate/update on partial views which after all is just a resource. It
should be possible with a PUT by specifying the subset as
(id,hasRead,offset,limit) or (id,hasRead,pageSize,page) and including the
@id and hasRead properties of all posts/comments within the subset.  There
is no need for things like json-patch to perform partial updates when the
resource represents a subset/view, it can just use PUT.

Regards,

Andrew


On Sun, Feb 15, 2015 at 10:18 PM, Tomasz Pluskiewicz <tomasz@t-code.pl>
wrote:

> Hi everyone
>
> In my latest response to Markus [1] I've expressed my concerns about
> defining any kind of navigation scheme for Hydra may be a bad idea.
>
> Having written that message I've come up with another though about partial
> representations.
>
> We all concern ourselves with collections. But what about another kind of
> resources which are large enough so that it may be served in multiple
> smaller chunks. Like an object with multiple collections. Each collection
> may be small but together the size becomes significant.
>
> /person/Tomasz
> /person/Tomasz/friends
> /person/Tomasz/interests
> /person/Tomasz/projects
> /person/Tomasz/hobbies
> /person/Tomasz/family
> etc.
>
> Each URI above could contain a partial view of
> /person/Tomasz and they would be linked by some custom properties.
>
> Isn't this similar to paging collection? My point is that a lot of time is
> being invested to define one very specific way for addressing partial
> representations (of collections) while a more general approach could be
> possible to tackle a multitude of similar cases.
>
> At the same time Hydra clients can be kept simpler because there is a
> general way for doing partial representation and for everything else there
> already are Links and IriTemplates...
>
> Thoughts?
>
> Regards,
> Tom
>
>
>