JSON Siren vs. HAL Representations

[nick.p...@gmail.com]

I was reading over this post and have some questions:

https://gist.github.com/kevinswiber/3066768

I'm having a hard time seeing how these two representations are similar.  The HAL representation has an embedded representation called "orders" which is a list (array) of orders (order list-item).  The SIREN representation has an two unnamed (that's the subject of another post of mine) embedded resources each of which are an order list-item.  How are these similar?  Shouldn't the SIREN embedded resource be an array of order list-item just like the HAL representation?  Is there a reason it's not represented that way?  What if I need to also embed another representation, something that's not an order list-item.  Will that most likely screw up the client if the assumption is that the entities array object in this case is an array of order list-item?

Thanks,
Nick

[Mark Derricutt]

On 12 Feb 2015, at 15:11, nick.p...@gmail.com wrote:

resources each of which are an order list-item. How are these similar?
Shouldn't the SIREN embedded resource be an array of order list-item just
like the HAL representation? Is there a reason it's not represented that

The flaw here is actually in the HAL representation example, which has been discussed a few times on the HAL list, the rel orders should actually be order in the example.

Under HAL - the rel key points to either a single embedded object, or a collection of embedded elements of the same rep-type. So whilst the physical serialisation is a collection against a single rel, the mental model is N separate embedded resources each with the same rel.

The HAL approach lets Javascript or dynamic folk simply refer to things like rep._embedded.order[1] which is quick, and dirty and lets you treat the serialisation format as your runtime object model.

The Siren approach instead requires you to navigate the set of embedded representations, pulling out those that match the order rel.

I think I prefer the Siren approach.

--
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt

[nick.p...@gmail.com]

I'm still a bit confused.  If I have a representation that normally would be represented as a json array if I navigated to the URL for that representation, if I want to embed it will it still be a json array within the entities array, or does the array have to get flattened within the entities array?

Thanks,
Nick

[nick.p...@gmail.com]

Still looking for clarification on this.  Can a SIREN embedding be an array object?

Thanks,
Nick

[Alex Soto]

Siren embedded entities (sub-entity) aren't collections, however, you can have a sub-entity that is a collection.

For example, I've done the following

/series/:id/episodes

The Series response has a sub-entity 'episodes' that is a collection of episodes.  The response for the for /series/:id/episodes entity contains one or more individual episode entities in it's entities collection.

If you want to see it 'for real' look through the docs for series, episodes and episode:

http://developers.wurl.com/pages/reference/entities/series

http://developers.wurl.com/pages/reference/entities/episodes

http://developers.wurl.com/pages/reference/entities/episode

If you see any discrepancies between the sample responses and the Siren spec, it's due to my implementation that we're slowly cleaning up as we go along :)

--
You received this message because you are subscribed to the Google Groups "Siren Hypermedia" group.
To unsubscribe from this group and stop receiving emails from it, send an email to siren-hypermed...@googlegroups.com.
To post to this group, send email to siren-hy...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/siren-hypermedia/a4f1d9d0-fc75-4539-84ff-6635db1f6f62%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.