Question about properties taking on different contexts

.... I think. Not sure how to phrase that ...

Anyway, hi :) I'm Daniel.

First of all, I apologise if this is the wrong place to ask — if so, I
accept rough responses and/or being ignored, and apologise for wasting
your time.

I do have a question though, that I find it hard to find an answer to.
I've been working with JSON-LD for a few days now, sketching out for
an API that is to be exposed way, way too soon to a customer of ours
who's building an iOS app. My colleague and I are trying to create an
just an initial simplified, bare-bones basic API where we do few
things, but try to do them as correctly as possible, so that we can
use this work as a stepping stone for a better, broader API. We like
JSON-LD, and are starting out with that :)

I've been mapping database structures to contexts, and am mucking
about with generating API responses. One thing I'm confused about is
how to properly present data related to the endpoint data when this
data should or should not be "expanded."

Allow me to explain with an example. Let's say we have an entity,
Post, which has a @context describing its properties and relations,
like author, comments, container, title, body, and so on. Here, author
would be referencing a User as described by another context, comments
a Comment context, etc.

So long as I am to return all of that data in full, it makes sense to
have e.g. somePost.comment be a ' "@type" : "mydomain:Comment" ' and
simply nest the comment object in the response.

On the other hand, if I am returning for instance search results,
where comments are not immediately to be used for anything, it makes
much more sense have somePost.comment be an IRI @id that references
"/Post/123/Comment" which could then be dereferenced to get the
comments for either one of the posts in the result set.

I cannot figure out, though, if this is an anti-pattern or if I am
just ignorant about how this is to be properly described in a
@context. AFAICT, I cannot describe that a property could be either an
IRI referencing something like "/Post/123/Comment", OR a @list
actually containing those comments. Will we have to choose either or?

In our case, for example, we default to returning lists of things in
batches of 25. A batch of aforementioned "Posts" in a search result
where you'll need to show the related author's name, a related status
title, and the title of the "box" it resides in, would require 76
requests on our API for each batch if we simply use IRIs to reference
those points (assuming the consumer just blindly dereferences each IRI
without comparing IRIs first).

On the other hand, if we choose to return all related data, we'll be
needlessly fetching comments and sending lots of additional data which
will eventually just be discarded.

What is the right way to approach this? I hope I'm allowed to ask this
question here, and that someone will have an answer for me :)

Thank you for your time!

Daniel

Received on Tuesday, 9 May 2017 11:49:05 UTC