What's the current thinking on "data" array elements whose "value" needs to be an array/object itself?

40 views
Skip to first unread message

Michael Dunn

unread,
Jan 12, 2015, 11:32:22 AM1/12/15
to collect...@googlegroups.com

First, apologies as this has probably been addressed multiple times before.

I just didn't see anything in forum when I searched...


So, I've got what I think is a fairly common use case that I'm trying to figure out how to address with Collection+JSON (or, if I even can).

I've got a collection, with my items. Now, one (or more) of my data attributes for the items is itself multivalued (ie. array or object). How should this be addressed?


According to the schema/media-type, it appears that "value" can only be a string.

It seems pretty basic that there would be a need to represented multivalue/complex values so I'm thinking that I really stupid and just missed something obvious. But I need help to see it.


I do see that someone submitted a registered extension for this... so is that the solution.


Here's an example collection representing my use case.


{
  "collection" :
  {
    "version" : "1.0",
    "items" :
    [
      {
        "data" : [

{“prompt”: “Username”, “name”: “username”, “value”: “mi...@example.com”},

{“prompt”: “Dimensions Granted to User”, “name”: “assignedDimensions”, “value”: [array]}


]
    ]
}
}

Thanks,
Mike Dunn

mca

unread,
Jan 12, 2015, 11:52:48 AM1/12/15
to collect...@googlegroups.com
Mike:

good to see your post.

Cj is designed to steer clear of embedding objects or even arrays as a code construct inside the messages. for that reason the baseline format does not support things like arrays or objects as "values".  the generic approach is to use a new collection for the array. IYC, the "assigned dimensions" is a collection itself (not an array *embedded* inside a collection) and the link to the assigned dimensions is on the collection.item["mi...@eample.com].links[{"rel":dimensions", ...."}] (sorry for the hacked, invalid JSON ;')

however, there are certainly times when there is a desire to optimize the message-passing and to conflate the two collections. there are a couple ways to approach that:
1 - i typically include both sets of data by creating a heterogeneous collection[1]. i use a convention of a "type" data element to describe which (in that example) is a user record, account record, or activity record and tie the records together using the "user" data element on the related items. admittedly, this convention has to be "baked" into the client in order to traverse it. To good new is any generic Cj client will still be able to render and manipulate all the info here.

2 - there is a registered cj extension to extend data elements to include objects and arrays[2]. it adds the "array" and "object" properties to a data element and you are on your own to do whatever you like in that array/object.  the good news is that you can write messages that look much more like "source code" and -- in the case of a JS client, use JSON.parse to "smuggle" complex objects directly into your client app. the bad news is that this stuff will be totally ignored by generic Cj clients and you'll get missing functionality.

3 - there is also an extension for inlineing complete collections[3] but i suspect this is not what you are looking for.

there are likely other approaches, but these are the ones readily available.

i'd like to hear more about what you are doing and why it is important to drop the Cj collection pattern and use embedded-style design instead.

cheers.





--
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 collectionjso...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Michael Dunn

unread,
Jan 12, 2015, 12:21:16 PM1/12/15
to collect...@googlegroups.com
Wow, that was quick.  Thank you.

My particular case is a bit weird.  I'm working on an integration with a vendor that has limited flexibility in terms of the number of HTTP calls that they can issue via their batch processing system (yuck already).

The problem in particular is that they won't be able to follow the hypermedia (thank you for your new book!) links to any other representations via their system.  So, I'm stuck needing to represent multi-value attributes for member/items of the collection in a single response.  

Perhaps in this case, given that it is for their particular integration, I can just use the extension that allows arrays/objects.  I hate to start out of the gate wandering off the trail (so to speak) though.

Here's another bit of weirdness - since you asked ;) - about the use case.  I'm also not allowed to call into their system (all HTTP calls have to originate from them), so I'm also having to allow them to POST a Cj object (which again has to have embedded data because I can't issue follow-up HTTP calls to get linked collections), accept it for processing, and then make something that looks like the example I provided available via GET after processing is complete.

This is getting really into the weeds of this particular implementation.  Please feel free to ignore anything that is too specific to be useful to the group discussion.

Mike Dunn

mca

unread,
Jan 12, 2015, 12:29:33 PM1/12/15
to collect...@googlegroups.com
yeah - sounds messy.

1) sounds like lots of tight coupling going on between you and this one vendor -- lots of a-priori info that is not sent in msgs -- that a generic Cj client will not be able handle. with that in mind, using the array/object extension is proly not going to hurt anyone. FWIW, i like the value-types extension option more than the inline one.

2) i;m not clear at all on the whole "don't call us, we'll call you" thing but one idea you might want to consider is creating a "local store" of the POSTed data for your own use (including reflecting out to the final clients). this would work quite well if the upstream service sends caching headers. that allows the upstream service to POST anytime and for your service to provide downstream messages on demand, right?

3) finally, if my notion of your set up (#2) is correct -- you don't need to use the same formats when talking to the upstream service as you do when talking w/ the downstream clients. IOW, you could use CJ w/ value-types ext to talk "up" and use anything you want (w/ as many repeated calls as you like) when formatting responses to downstream clients.

just a thought



--
Reply all
Reply to author
Forward
0 new messages