Also support optional HAL Link fields

[edrik]

The HAL support so far is great but for it to be really usable the optional link fields defined by the HAL specification should also be available.

There is a pull request #79 about adding a type and title but there are allot more optional fields defined by HAL. Not sure if adding all the fields to the Link class is the best solution but that would be a quick fix.

So far I've used a extended version of the Link class that adds the fields (and a fix for the issue with selecting the appropriate JsonSerializer, also noticed by #88). But that is far from ideal and makes allot of the convenience method unusable.

Any thoughts on how this could be implemented in a reasonably unobtrusive manner?

[fiddlerpianist]

I'm frankly kind of surprised that Link isn't an interface (particularly since they are usually built with Builders rather than being instantiated directly). Also, why is the Atom namespace is coded directly onto the class? This makes it difficult and cumbersome to support HAL and in some cases actually deviates from Atom expectations. For instance, since href in HAL can be a URI template if the templated property is set to true, that means that the value in some cases is non RFC-5899 compliant.

I'm all for having Link be a link abstraction, but right now it seems like it's too close to Atom.

[drewcox]

I've done a lot of searching and this post seems to be the closest I've got to figuring out if I can build HAL template resource links with Spring HATEOAS. e.g "http://host/resource1/{id}/subResource". The answer appears to be "no". At best it tries to encode the "{", "}" chars, thinking I am trying to build a valid URL, not a templated one per http://tools.ietf.org/html/rfc6570.

[fiddlerpianist]

drewcox: My fork adds a method to the Link class that renders the HAL template: true for URIs that have curly braces. I realize that doesn't cover everything, but it's a start to intuit whether a URI is a template. I've submitted a pull request for this addition.

[drewcox]

Hey, thanks for the quick response. Kind of new to GitHub, is it possible for me to access your fork? Thanks Drew

[fiddlerpianist]

Yes. It's at https://github.com/fiddlerpianist/spring-hateoas. Look for recent commits from me.

[jiwhiz]

I'm trying to figure out how to build HAL links with "templated: true". If I use

BasicLinkBuilder.linkToCurrentMapping().slash("api/public/blogs/{blog}").withRel("blog");

The '{' and '}' chars are still encoded. Any idea how to build template URL links with Spring-hateoas 0.10.0.RELEASE by its API?

Thanks.

[rodriguezrps]

jiwhiz: you have a solution for the templated: true?

[jiwhiz]

@rodriguezrps yes, found some tricks.

I can use UriTemplate to build link directly with template, such as

String baseUri = BasicLinkBuilder.linkToCurrentMapping().toString();
Link blogsLink = new Link(
    new UriTemplate(baseUri + ApiUrls.API_ROOT + ApiUrls.URL_AUTHOR_BLOGS),
    AuthorAccountResource.LINK_NAME_BLOGS);

And use PagedResourcesAssembler to append pagination templates:

resource.add(assembler.appendPaginationParameterTemplates(blogsLink));

You can see examples at my blog https://www.jiwhiz.com/post/2014/4/Design_and_Build_RESTful_API_with_Spring_HATEOAS

[cperez1000]

@edrik : can you please post your solution? It'd be very helpful.

[edrik]

There is nothing special about the solution I'm using now. Its a extended version of the Link class that adds the attributes and can be construkted from an existing Link. Just need to do some extra wrapping in some places but its a reasonably workaround.

CustomLink halLink = CustomLink.of( plainLink ).setTitle("Foo")

[cperez1000]

@edrik
Thanks.. I had ended up doing the same thing, Just decorated Link to be able to still use the convenience methods.

[odrotbohm]

Fixed with #567.