How to create nested template data?
176 views
Skip to first unread message
Josh
Jun 13, 2013, 9:57:44 AM6/13/13
to collect...@googlegroups.com
For example, say the template I want to model a datamodel called Applicant with name, and multiple addresses (of type - postal, home, work etc..., and street, country, etc...)
How can I show the collection of Address in the template below?
"template" : {
{
"data" :
[
{"name" : "name", "value" : "Unnamed"},
]
}
Please advice
mca
Jun 13, 2013, 10:47:07 AM6/13/13
to collect...@googlegroups.com
Josh:
good to see your Q here.
Cj was initially design to _not_ support embedded objects or deep graphs. however, there is at least one extension registered at the github site for Cj called "inline Collections"[1]. I'm not sure if anyone is actually using that extension (anyone here?) and I'm open to other extension ideas that don't break the current model.
On another POV, I've created responses that have a "mixed type" model in the list. For example, a single response where the items[] collection contains both order-header and order-detail-lines. In these cases, I include a "type" element in the data collection("type":"order" OR "type":"detail") and, for the detail items, include a parent identifer ("parent" : "http://....."). This allows me to do a kind of nesting w/o introducing a new construct to the message model.
Feel free to let me know what it is your are working on, whether the current extension helps, if you think you need something else, etc.
Cheers.
mca
--
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/groups/opt_out.
Josh
Jun 14, 2013, 1:40:24 AM6/14/13
to collect...@googlegroups.com
Hi Mike,
Thanks for the reply, basically I am trying to create a loan application system where by people can submit an application to the system to be processed. I am still new to Rest/HATEOAS, so forgive me for my silly questions or assumptions I might have.
The complex part of this, is the actual Application data required which includes the Loan Details, Applicants, Products, Address, Assets, Liabilities and the whole lot, plus a whole bunch of validation / business rules.
I am currently prototyping a conceptual model, and I do think HATEOAS/REST/Hypermedia is a valid fit for this scenario, which is why I am wrapping my head around it at the moment.
Maybe Collection+JSON is not the most appropriate format for me, am also looking at SIREN and HAL suggested by many others on the web.
I have read a couple of books, Building Hypermedia with Node js and HTML5 by yourself and also the REST in Practice book, which inspired me to try building a RESTFUL API for my scenario.
With all the restbucks examples in REST in Practice book, I see a lot of similarities to what I want to achieve. I am still getting my head around all these Media Types available, and looking at the documentation to find the most suitable one for my need.
What I have identified so far, I have a few states, New/Pending, Cancelled, ValidationError, Expired, Submitted, Success, and Rejected for a Loan Application System. I need to transfer a Model/Payload/DTO of a very complicated, deeply nested object hierarchy Per Application as described above, which I plan to document it in like a /docs url or something. As different lenders would have different rules for validation, I guess the root url will contain links to a list of lenders? But at some point, I need to do a submission based on that large payload, or how can I break them down?
I guess in terms of Hypermedia Design elements, would the template area in Collection+Json be considered an Ad-Hoc (In Message Hypermedia Control) State Transfer pattern? Which I guess I do not need? Maybe a Predefined (External Documentation) State Transfer pattern is more suitable in my scenario? I do want a Generic or Agnostic domain style, because of the varying data structure requirements for different lenders, which is why I find Collection+Json quite suitable? Application flow can be applied or intrinsic I am not fussed as there are only a limited set of states.
With regards to the extension, I am still fuzzy as to how to use it, but would it mean that all sub items is a resource in itself? Maybe I am doing it wrong, but I have a resource path of "Application" only, I do not have resources of say "Applicants/Address" etc... they are all part of Application, but they can be documented. As when applying for a loan, I need the whole chunk, there is no point in partial updates to certain path/parts of the model only. In the example, "http://example.org/comments/1,2,3,4": { /* embedded collection+json */ }, which means the payload of the inline collection is of another resource?
So do you have any advice or mediatypes suggestions for me? Maybe I do not need to use the template part, so HAL is probably more suitable?
Thanks in advance.
Josh
mca
Jun 14, 2013, 10:29:23 AM6/14/13
to collect...@googlegroups.com
Josh:
yeah, if nesting within a representation is essential, Cj will not be a good fit for you w/o a specific extension.
one approach you could take is to define an "object" property of an item. Here's a gist that shows the added property: https://gist.github.com/mamund/5782142 You could do a bit more by adding some wrapper metadata around the graph like this:https://gist.github.com/mamund/5782198 There are other possibilities, too.
<snip>Maybe a Predefined (External Documentation) State Transfer pattern is more suitable in my scenario?</snip>
You ask a very good question. How much information about transfers do you want to include in the message (in a way that generic clients can understand) and how much information about transfers do you just want to "bake into the code" for this particular service? Cj is designed to require very little information "baked into the code" in order to support a wide range of transfer needs. To do that, I limit the "shape" of the transfer to a simple data array (queries handle data arrays as URL params, templates handle data arrays as a raw payload).
If it turns you you cannot find a reasonable way to shape your transfers in this way (e.g. your problem domain *requires* nested transfers), using Cj means you need to bake things into code.
Not sure if there are other formats that allow you to use nested transfer objects that do not require additional "code baking", but would be happy to hear about it.
Cheers.
Kevin Swiber
Jun 14, 2013, 11:08:54 AM6/14/13
to collect...@googlegroups.com
Hey Josh,
Not too long ago, I worked for a big mortgage company. The business domain was ridiculously complex, so I feel your pain.
/*
Side note:
In my experience, the most difficult piece of software development is getting the domain model right. This takes working with a lot of stakeholders to develop a common language and getting everyone (even different business people) on the same page when it comes to defining "what you do" in various business processes. (See Domain Driven Design for lots of good tips on this.)
Once the domain model is well-defined (maybe it already is), it will be easier to derive an API model.
*/
One strategy you can take is to create an Application resource to which other resources can be related. In Cj, I think this would be represented as an Application item that has related resources (links) to Lender, Address, Assets, and Liabilities collections. The Assets collection representation, for example, could have a template for adding a new asset with a data element containing { name: "applicationId", value: "app13432" }. (Sorry if that's confusing. An example JSON document would probably be easier to parse.)
The benefit of this is that managing validation and resource state become a lot easier. The trade-off is more network calls for better complexity management.
Regarding various formats required by different lenders, it may be in your best interest to define a standard that is right for you and offer "alternate" representations with lender-specific formats. There will be some data mapping that needs to happen on the backend, but such is the nature of working in a domain without standards.
Good luck!
On Fri, Jun 14, 2013 at 1:40 AM, Josh <jos...@gmail.com> wrote:
Josh
Jun 16, 2013, 12:49:35 AM6/16/13
to collect...@googlegroups.com
Hey Kevin and Mike,
Thanks for the wonderful suggestions, but I came across something called OData and have been reading more about it at the moment. Do u happen to know whether it is a hypermedia type or RESTFUL for that matter, as I am currently a little confused as to what exactly is oData(Microsoft) or gdata (google). Would you reckon it will be a good fit for my scenario?
Josh
Mike Amundsen
Jun 16, 2013, 1:53:19 AM6/16/13
to collect...@googlegroups.com
i can't say whether OData is a good fit for you. OData and Cj are both derived from Atom/AtomPub; each having their own strengths/weaknesses.
I'll also add that HAL has many features of Atom/OData as it, too, supports arbitrary object graphs within a resource response.
Josh
Jun 16, 2013, 3:16:57 AM6/16/13
to collect...@googlegroups.com
Have also been reading about Json-LD, is it a media type as well? Some says its a Serializable RDF representation in JSON, but some treats it as a media type coz it does fulfill it by having links?
I am confused.
mca
Jun 16, 2013, 11:27:54 AM6/16/13
to collect...@googlegroups.com
JSON-LD has not yet registered as a media type, but the docs are prep'd: http://www.w3.org/TR/2013/WD-json-ld-20130411/#application-ld-json
"Some says its a Serializable RDF representation in JSON, but some treats it as a media type" <-- FWIW, these are not mutually exclusive statements ;)
not sure where your confusion lies, but one way to evaluate media types for use in hypermedia is to use H-Factors[1]. go through the documentation and identify all the elements in the media type that fulfil one ore more of the H-Factors. That will give you a sense of how much "hypermedia support" is built into the media type design and how much you'd have to add using convention and code.
Reply all
Reply to author
Forward
0 new messages