Re: Pagination best practices

This may not be the most popular suggestion on a JSON-LD list, but there's
always JSON Hyper-Schema :-)


I've seen at least one group (W3C Web of Things) looking at using both
JSON-LD and JSON Schema, although they are not looking only at validation,
not Hyper-Schema.  But JSON Hyper-Schema doesn't care what your collection
and pagination look like, it just provides tools to express what links are
available.

thanks,
-henry


On Mon, May 22, 2017 at 11:02 PM, Daniel Smedegaard Buus <
danielbuus@gmail.com> wrote:

> Okay, you guys are using a lot of slightly confusing terminology :D
>
> What I don't like about the Hydra approach is that it encapsulates my
> type with its own "Collection" type, so instead of having, say, a
> property "users" which is of @type "mycontext:User", it is now the
> generic hydra:Collection @type, which then can contain a
> "hydra:member" property where each item in it has to declare their
> actual type of "mycontext:User".
>
> Not only does it obfuscate the context from expressing exactly what
> type a property will contain, it also loosens the contract to the
> consumer, allowing me as a producer to throw anything in there (the
> generic hydra:Collection). At least AFAICT, but as I said, I'm two
> weeks in ;) I'd much rather be able to "augment" a graph with a couple
> of extra meta properties which would contain this pagination data. But
> as I understand it, any context "extras" that go into a @graph node
> apply to items in the graph, not to the graph...
>
> When I started out two weeks back, I also briefly considered the Range
> header, but there are a couple of reasons why I don't want to go that
> route:
> 1) The Range header has a completely different meaning
> 2) I have much more information that I want to convey and consume,
> such as number of pages, links to pages, sorting, etc., and they don't
> fit in there either.
> 3) HTTP headers are, well, HTTP-gnostic. I'd like my API to be
> transport-agnostic. And apart from that, putting pagination
> information in a header transfers state from the document to the
> transport layer, and I really want the API to offer REST in and of
> itself, and in all possible transport scenarios, be it HTTP, RPC, Unix
> sockets or carrier pigeons :D.
>
> Am I correct in assuming that as of the current JSON-LD specification
> goes, I cannot "augment" something like a @graph to "put extra stuff
> in there, like pagination metadata" without having to put it onto
> items in the graph?
>
> I'll have another look at the ActivityStream concept, but it's not so
> much *how* I should paginate data as much as it is how I can avoid any
> approach "messing" with my contexts. I realize that JSON-LD is more
> about linking data than it is about schemafying your data, but the
> schema part of JSON-LD is fantastic IMHO. I love that right now, I can
> tell our outhouse iOS developers to pull the contexts, and it's
> immediately apparent what they can expect to get. User.comments is of
> type mycontext:Comment. Easy.
>
> If anyone sees any way that I can keep my contexts as accurate as they
> are now, but be able to add pagination metadata to a document, I'd
> love the input :) (For one, I'd love to see an example of how those
> ActivityStream concept have been incorporated into a JSON-LD
> document!)
>
> Thanks again, all, for all your thoughts!
>
> Daniel
>
>


-- 

   -

   *Henry Andrews*  |  Systems Engineer
   henry@cloudflare.com
   <https://www.cloudflare.com/>

   1 888 99 FLARE  |  www.cloudflare.com
   -