The _embedded property seems to get questioned a lot.. people ask why it is needed and why HAL doesn't have a model whereby resources are embedded directly, i.e.:
I designed it this way so that resources would be embedded explicitly in the containing object which would be more efficient to parse, since the alternative requires a parser to run through the entire object hierarchies to look for a _links property and established what the embedded resources are.
I guess the benefit of not using _embedded is that it is 'simpler' and less convoluted.. I just can't make up my mind which is the better option - I was wondering if anyone had any strong preferences or further insights on the pros and cons?
I haven't had to write a JSON parser for this yet so maybe I'll regret
saying this but...I like the first option better. The reason is
because it makes things more elegant for the consumer not to have to
refer to this odd "_embedded" property when working with the code. My
vote is to err on making the life easier for human consumers rather
than parsers.
On Jan 25, 10:37 am, Mike Kelly <mikekelly...@gmail.com> wrote:
> The _embedded property seems to get questioned a lot.. people ask why it is
> needed and why HAL doesn't have a model whereby resources are embedded
> directly, i.e.:
> I designed it this way so that resources would be embedded explicitly in
> the containing object which would be more efficient to parse, since the
> alternative requires a parser to run through the entire object hierarchies
> to look for a _links property and established what the embedded resources
> are.
> I guess the benefit of not using _embedded is that it is 'simpler' and less
> convoluted.. I just can't make up my mind which is the better option - I
> was wondering if anyone had any strong preferences or further insights on
> the pros and cons?
steve.michelo...@gmail.com> wrote: > I haven't had to write a JSON parser for this yet so maybe I'll regret > saying this but...I like the first option better. The reason is > because it makes things more elegant for the consumer not to have to > refer to this odd "_embedded" property when working with the code. My > vote is to err on making the life easier for human consumers rather > than parsers.
> On Jan 25, 10:37 am, Mike Kelly <mikekelly...@gmail.com> wrote: > > The _embedded property seems to get questioned a lot.. people ask why it > is > > needed and why HAL doesn't have a model whereby resources are embedded > > directly, i.e.:
> > I designed it this way so that resources would be embedded explicitly in > > the containing object which would be more efficient to parse, since the > > alternative requires a parser to run through the entire object > hierarchies > > to look for a _links property and established what the embedded resources > > are.
> > I guess the benefit of not using _embedded is that it is 'simpler' and > less > > convoluted.. I just can't make up my mind which is the better option - I > > was wondering if anyone had any strong preferences or further insights on > > the pros and cons?
I thought, that it is especially important for a hypermedia driven application client to know which resource is (partly or completely) transcluded into the requested resource (root resource). It states, amongst others, that this information about that resource is enough at the moment to step into another application state (, i.e. make a choice for a next step). So, one does not have to dereference the URI of that resource before (as it would maybe the case in RDF). Otherwise, I would tend to say that HAL is then closer aligned to knowledge representation languages la RDF ;)
> The _embedded property seems to get questioned a lot.. people ask why it > is needed and why HAL doesn't have a model whereby resources are > embedded directly, i.e.:
> I designed it this way so that resources would be embedded explicitly in > the containing object which would be more efficient to parse, since the > alternative requires a parser to run through the entire > object hierarchies to look for a _links property and established what > the embedded resources are.
> I guess the benefit of not using _embedded is that it is 'simpler' and > less convoluted.. I just can't make up my mind which is the better > option - I was wondering if anyone had any strong preferences or further > insights on the pros and cons?
But what I'm wondering about is the way *list resources* are
presented. Could we also ave the simple "association" way or is this
not consistent with the HAL ideas?:
{
"_links": {
"self": { "href": "/orders" },
"next": { "href": "/orders?page=2" },
"search": { "href": "/orders?id={order_id}" }
"order": [
{ "href": "/orders/123", "title": "order 123 from Wed, Jan 25,
2012 at 4:00 PM" },
{ "href": "/orders/124", "title": "order 124 from Wed, Jan 25,
2012 at 4:01 PM" },
{ "href": "/orders/125", "title": "order 125 from Wed, Jan 25,
2012 at 4:02 PM" },
{ "href": "/orders/126", "title": "order 126 from Wed, Jan 25,
2012 at 4:03 PM" },
{ "href": "/orders/127", "title": "order 127 from Wed, Jan 25,
2012 at 4:04 PM" },
{ "href": "/orders/128", "title": "order 128 from Wed, Jan 25,
2012 at 4:05 PM" },
{ "href": "/orders/129", "title": "order 129 from Wed, Jan 25,
2012 at 4:06 PM" }
]
}
}
Have fun, enjoy,
Kai-Uwe
On 25 Jan., 16:37, Mike Kelly <mikekelly...@gmail.com> wrote:
> The _embedded property seems to get questioned a lot.. people ask why it is
> needed and why HAL doesn't have a model whereby resources are embedded
> directly, i.e.:
> I designed it this way so that resources would be embedded explicitly in
> the containing object which would be more efficient to parse, since the
> alternative requires a parser to run through the entire object hierarchies
> to look for a _links property and established what the embedded resources
> are.
> I guess the benefit of not using _embedded is that it is 'simpler' and less
> convoluted.. I just can't make up my mind which is the better option - I
> was wondering if anyone had any strong preferences or further insights on
> the pros and cons?
This is still the same transclusion mechanism, the difference is really only in the way in which the translusion is modeled in JSON.
It only affects how clients are required to establish what resources are transcluded for a given resource; since removing _embedded would potentially require clients to iterate over all properties of a resource object and determine whether or not they are transclusions. This would be an expensive process for large resources with many properties.. having said that iterating over to establish all the available transclusions is only really necessary in a 'discovery' situation, and not really needed if the client already knows which transclusions it is looking for.
On Wed, Jan 25, 2012 at 4:50 PM, Bob Ferris <z...@smiy.org> wrote: > Hi Mike,
> I thought, that it is especially important for a hypermedia driven > application client to know which resource is (partly or completely) > transcluded into the requested resource (root resource). It states, amongst > others, that this information about that resource is enough at the moment > to step into another application state (, i.e. make a choice for a next > step). So, one does not have to dereference the URI of that resource before > (as it would maybe the case in RDF). > Otherwise, I would tend to say that HAL is then closer aligned to > knowledge representation languages á la RDF ;)
> Cheers,
> Bo
> On 1/25/2012 4:37 PM, Mike Kelly wrote:
>> The _embedded property seems to get questioned a lot.. people ask why it >> is needed and why HAL doesn't have a model whereby resources are >> embedded directly, i.e.:
>> I designed it this way so that resources would be embedded explicitly in >> the containing object which would be more efficient to parse, since the >> alternative requires a parser to run through the entire >> object hierarchies to look for a _links property and established what >> the embedded resources are.
>> I guess the benefit of not using _embedded is that it is 'simpler' and >> less convoluted.. I just can't make up my mind which is the better >> option - I was wondering if anyone had any strong preferences or further >> insights on the pros and cons?
The beginning of the second paragraph isn't very clear, should've been this:
"It only affects how clients are required to establish what transclusions exist for a given resource; since removing _embedded would require clients to iterate over all properties of a resource object in order to determine which of them are transclusions (i.e. selecting properties that are objects and have their own _links property)"
On Wed, Jan 25, 2012 at 5:02 PM, Mike Kelly <mikekelly...@gmail.com> wrote: > Hi Bob,
> This is still the same transclusion mechanism, the difference is really > only in the way in which the translusion is modeled in JSON.
> It only affects how clients are required to establish what resources are > transcluded for a given resource; since removing _embedded would > potentially require clients to iterate over all properties of a resource > object and determine whether or not they are transclusions. This would be > an expensive process for large resources with many properties.. having said > that iterating over to establish all the available transclusions is only > really necessary in a 'discovery' situation, and not really needed if the > client already knows which transclusions it is looking for.
> Cheers, > Mike
> On Wed, Jan 25, 2012 at 4:50 PM, Bob Ferris <z...@smiy.org> wrote:
>> Hi Mike,
>> I thought, that it is especially important for a hypermedia driven >> application client to know which resource is (partly or completely) >> transcluded into the requested resource (root resource). It states, amongst >> others, that this information about that resource is enough at the moment >> to step into another application state (, i.e. make a choice for a next >> step). So, one does not have to dereference the URI of that resource before >> (as it would maybe the case in RDF). >> Otherwise, I would tend to say that HAL is then closer aligned to >> knowledge representation languages á la RDF ;)
>> Cheers,
>> Bo
>> On 1/25/2012 4:37 PM, Mike Kelly wrote:
>>> The _embedded property seems to get questioned a lot.. people ask why it >>> is needed and why HAL doesn't have a model whereby resources are >>> embedded directly, i.e.:
>>> I designed it this way so that resources would be embedded explicitly in >>> the containing object which would be more efficient to parse, since the >>> alternative requires a parser to run through the entire >>> object hierarchies to look for a _links property and established what >>> the embedded resources are.
>>> I guess the benefit of not using _embedded is that it is 'simpler' and >>> less convoluted.. I just can't make up my mind which is the better >>> option - I was wondering if anyone had any strong preferences or further >>> insights on the pros and cons?
> But what I'm wondering about is the way *list resources* are > presented. Could we also ave the simple "association" way or is this > not consistent with the HAL ideas?:
Hello - yes that is a valid use of a _links property in hal+json, it's written into the spec:
"Relations with one corresponding Resource/Link have a single object value, relations with multiple corresponding HAL elements have an array of objects as their value."
Is that what you meant? Maybe this needs to be clearer?
+1 on the current design. It's preferable for me that there's a separation between a resource and another. Also, given that embedded resources have rels which identify how they relate, having the container object makes a lot of sense. I don't see how you'd do that otherwise, unless you embed inside the resource the _rel which implies following a resource THEN finding out WHY you followed it :)
-- "Great artists are extremely selfish and arrogant things" — Steven Wilson, Porcupine Tree
On Thu, Jan 26, 2012 at 4:37 AM, Mike Kelly <mikekelly...@gmail.com> wrote: > I guess the benefit of not using _embedded is that it is 'simpler' and > less convoluted.. I just can't make up my mind which is the better option - > I was wondering if anyone had any strong preferences or further insights on > the pros and cons?
I have written a JSON and XML parser recently in JavaScript and having
_embedded made the solution a lot simpler, more elegant and
performant. In this case the client does not know what transclusions
it is looking for, nor could it. Please keep the current design for
this.
Cheers,
Isaac
On Jan 26, 4:37 am, Mike Kelly <mikekelly...@gmail.com> wrote:
> The _embedded property seems to get questioned a lot.. people ask why it is
> needed and why HAL doesn't have a model whereby resources are embedded
> directly, i.e.:
> I designed it this way so that resources would be embedded explicitly in
> the containing object which would be more efficient to parse, since the
> alternative requires a parser to run through the entire object hierarchies
> to look for a _links property and established what the embedded resources
> are.
> I guess the benefit of not using _embedded is that it is 'simpler' and less
> convoluted.. I just can't make up my mind which is the better option - I
> was wondering if anyone had any strong preferences or further insights on
> the pros and cons?
> I have written a JSON and XML parser recently in JavaScript and having
> _embedded made the solution a lot simpler, more elegant and
> performant. In this case the client does not know what transclusions
> it is looking for, nor could it. Please keep the current design for
> this.
> Cheers,
> Isaac
> On Jan 26, 4:37 am, Mike Kelly <mikekelly...@gmail.com> wrote:
> > The _embedded property seems to get questioned a lot.. people ask why it is
> > needed and why HAL doesn't have a model whereby resources are embedded
> > directly, i.e.:
> > I designed it this way so that resources would be embedded explicitly in
> > the containing object which would be more efficient to parse, since the
> > alternative requires a parser to run through the entire object hierarchies
> > to look for a _links property and established what the embedded resources
> > are.
> > I guess the benefit of not using _embedded is that it is 'simpler' and less
> > convoluted.. I just can't make up my mind which is the better option - I
> > was wondering if anyone had any strong preferences or further insights on
> > the pros and cons?
