multiplicity of links when building objects on a client

17 views
Skip to first unread message

John Leedham

unread,
Oct 19, 2016, 9:31:40 AM10/19/16
to Collection+JSON
Hi,

I have a system where I am constructing C+J for a collection of items, and those items refer to other collections (and in particular to subsets thereof).

Consider a hypothetical system with people, houses and cars. Each person has one house, but can have more than car, but more than one person can live in a house, and a car can be shared between multiple people. A pretty standard set of one-to-many and many-to-many relationships

I am currently modelling this along these lines:

"items" : [
{    "href" : "/people/1"
.... "data" : [ { name : name, value : "john"} ],
     "links" : [ { rel : "cars", href="/cars?where=reg=123ABC1 or reg=456EFG1" }, { rel : "house", href="/houses/1" }
}]

In essence, the relations are links which return the related items. All good so far (although if I am misunderstanding how I should expose such relationships, please let me know)

My question is what to do when I reassemble an object model on the client end. In the spirit of not having prior structural information (i.e. that a person has one house but 1 or more cars), I am wondering how to derive from the above that the property house should be one-to-many, but cars should be many to many. In particular, when the number of cars is 1 not 2. In essence, the difference between a and [a].

The primary issue is that /houses/1 returns a collection with a single item in it, and this can't be differentiated from the filtered collection of cars, which also returns a collection with a single item if there is only 1 car. Without doing something horrible (like noting that all properties that end with an s should be converted to lists, whereas those without should be single properties), is there a way to achieve what I want with the basic C+J standard? If not, is there already a suitable extension?, and if not, suggestions as to a suitable approach would be gratefully accepted.

There is a similar issue with the template, if I want to specify the car/house from the person, but I suspect the direction to go for that will fall out of the same answers.

John

John Leedham

unread,
Oct 19, 2016, 10:06:20 AM10/19/16
to Collection+JSON
I have also tried doing it as:

"items" : [
{    "href" : "/people/1"
.... "data" : [ { name : name, value : "john"} ],
     "links" : [ { rel : "car", href="/cars/123ABC1" }, { rel : "car", href="/cars/456EFG1" }, { rel : "house", href="/houses/1" }
}]

which has some nice aspects, although I quite like the fact that I can do a plural in the UI representation with the first version of the rel which isn't necessarily just adding an 's'.

However, this still suffers from the same problem regarding multiplicity

John

mca

unread,
Oct 19, 2016, 9:47:31 PM10/19/16
to collect...@googlegroups.com
John:

keep in mind that the @rel property can be a space-separated list of values. with this in mind, you can use the RFC-defined "item" and "collection" rel values to give clients hints about the expected nature of the representation at the other end of a link.

for example...

"items" : [
{    "href" : "/people/1"
.... "data" : [ { name : name, value : "john"} ],
     "links" : [ { rel : "cars collection", href="/cars?where=reg=123ABC1 or reg=456EFG1" }, { rel : "house item", href="/houses/1" }
}]

you still need to write a client that has custom behavior for these values. that means a generic client will not behave the same way your customized client does. 

but at least this is a way to include the additional info w/o making any changes/extensions to Cj

hope this helps.

--
You received this message because you are subscribed to the Google Groups "Collection+JSON" group.
To unsubscribe from this group and stop receiving emails from it, send an email to collectionjson+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

John Leedham

unread,
Oct 20, 2016, 5:39:47 AM10/20/16
to Collection+JSON
Thanks for chiming in.

I can see how that would work, although it's a shame since I have espousing the virtue of being able to point it at any generic client (my application actually works rather well with your Javascript one in other respects - to the extent that someone I showed it to just said 'why don't we use that', although the idea was quickly squashed for commercial reasons). I had hoped I may have missed something!

I suspect that in actuality, our API is only going to be used in situations where we either define the client, or have the ability to direct its construction, but my aim has been to as far as possible allow the notion of a near vanilla one.

I shall have a play with the item and collection rel and see how it works out.

John
To unsubscribe from this group and stop receiving emails from it, send an email to collectionjso...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages