Hal support is incomplete

[dschulten]

My experiments with the Hal support gave me this for a Resource having an attached Resources object. The Resource is Thorin, his belongings are the embedded Resources. I added a describedBy rel to each Resource and to Resources just for demonstration purposes.

{
    "firstname": "Thorin",
    "lastname": "Oakenshield1",
    "products": {
        "content": [
            {
                "productName": "Orcrist",
                "_links": {
                    "self": {
                        "rel": "self",
                        "href": "http://localhost:8080/products/1"
                    },
                    "describedBy": {
                        "rel": "describedBy",
                        "href": "http://example.com/doc#product"
                    }
                }
            }
        ],
        "_links": {
            "describedBy": {
                "rel": "describedBy",
                "href": "http://example.com/doc#products"
            }
        }
    },
    "_links": {
        "self": {
            "rel": "self",
            "href": "http://localhost:8080/people/1"
        },
        "describedBy": {
            "rel": "describedBy",
            "href": "http://example.com/doc#customer"
        }
    }
}

This is not the correct HAL representation of a resource with embedded resources. The correct representation should be:

{
    "firstname": "Thorin",
    "lastname": "Oakenshield1",
    "_embedded": {
        "products": [
            {
                "productName": "Orcrist",
                "_links": {
                    "self": { "href": "http://localhost:8080/products/1"},
                    "describedBy": {"href": "http://example.com/doc#product"}
                }
            }
        ],
        "_links": {
            "describedBy": {"href": "http://example.com/doc#products"}
        }
    },
    "_links": {
        "self": {"href": "http://localhost:8080/people/1"},
        "describedBy": {"href": "http://example.com/doc#customer"}
    }
}

For decent HAL support we would also need templated URIs, for something like:

"find": { "href": "/orders{?id}", "templated": true }

[Laures]

because of the way spring-hateoas is written (everything uses ResourceSupport) i don't (or in this case didn't) see an easy way to support _embedded. there is no place to (for example) add a dedicated field for embedded resources.

do you have a suggestion how content for "_embedded" could be recognized during serialization?

the same goes for additional hal specific properties for link objects. one could introduce a hallink serializer that auto-detects the value of templated, but imho a generic way to add custom properties to a link would be better

[bripkens]

I would really like to see support for the format which is described in draft-kelly-json-hal-03 as this would improve interoperability with existing solutions, for instance, with the ones listed on the HAL Specification website.

[Laures]

the only way i see that would be possible (short of changing spring-hateoas into a hal implementation) would be to make the resourcesupport + link structure more extensible.

For example you could turn the link list of ResourceSupport into a collection of "relations" and leave the handling of different relation types (for example subclasses of Link) to the (de)serialization layer. then you could implement a link-relation (same as link is now) and an "embedded-resource" relation (for _embedded) and so on.

In addition the link relation could be extended with a map of properties to make "templated" and all the other hal properties possible.

I might give this idea a try.

[dschulten]

The Resources class already has a content element which is conceptually
similar to the _embedded item.
Maybe you can use that?

It might also make sense to have a different LinkTemplate type, for a
Link href can be dereferenced, whereas a LinkTemplate href must not be
dereferenced without prior expansion. Maybe Link and LinkTemplate are
both Relations having a rel String.

Just some thoughts...

Dietrich

Am 5. Januar 2013 15:57:26 schrieb Alexander Bätz [email protected]:

the only way i see that would be possible (short of changing
spring-hateoas into a hal implementation) would be to make the
resourcesupport + link structure more extensible.

For example you could turn the link list of ResourceSupport into a
collection of "relations" and leave the handling of different relation
types (for example subclasses of Link) to the (de)serialization layer.
then you could implement a link-relation (same as link is now) and an
"embedded-resource" relation (for _embedded) and so on.

In addition the link relation could be extended with a map of
properties to make "templated" and all the other hal properties possible.

I might give this idea a try.

---

Reply to this email directly or view it on GitHub:
#36 (comment)

[Laures]

took some time but i finally had some time to look at the hal spec. i guess @dschulen is right. collections of resources are supposed to be serialized in the _embedded property. there is an example for this directly on the json-hal page ( http://stateless.co/hal_specification.html ). See also the discussion on the google group https://groups.google.com/forum/?fromgroups=#!topic/hal-discuss/bCzydTlHB3M

I've written a serializer for resources to create the necessary json structure (that i don't really like). i will also add deserializers for json-hal and push everything asap.

for the current code see: https://github.com/Laures/spring-hateoas/tree/hal-extension

[dschulten]

As far as I am concerned, this issue can be closed. We have embedded items now. Thank you Laures!

[drewcox]

Any plans to add the templated URL support for HAL?

[tombee]

@Laures @olivergierke @dschulten
How did you get this working in the end? I have been trying to embed additional Resources in my response, but using your example, I am ending up with something that looks like:

{
    "firstname": "Thorin",
    "lastname": "Oakenshield1",
    "products": {   <--- additional products collection
        "_embedded": {
           "products": [
            {
                "productName": "Orcrist",
                "_links": {
                    "self": { "href": "http://localhost:8080/products/1"},
                    "describedBy": {"href": "http://example.com/doc#product"}
                }
            }
          ],
           "_links": {
            "describedBy": {"href": "http://example.com/doc#products"}
           }
        },
    },
    "_links": {
        "self": {"href": "http://localhost:8080/people/1"},
        "describedBy": {"href": "http://example.com/doc#customer"}
    }
}

[rrocca]

Any one on this last question ? I'm struggling to obtain the same representation as tombee and trying out the Resources class, I get first "products" and then "_embedded" while I want the opposite.

[elnur]

I'm interested in this as well.

[harttamale]

+1

[TomStandaert]

+1

[jiwhiz]

I got same result like @tombee. @olivergierke @dschulten can we re-open this issue?

[pivovarit]

I am starting working on this issue on my own. Let's see what I can do.

There is a simple way of 'hacking' _embedded creation in your projects by extending ResourceSupport and building _embedded map by yourself.

[elnur]

@pivovarit good luck! 👍