Refactor to remove HalBuilder

[gary-rowe]

HalBuilder appears to introduce more complexity than is required for HAL support. Refactoring would include:

• all DTOs to inherit from EntityDto
• EntityDto to have Map<String,List> for _links
• EntityDto to have Map<String,List> for _embedded

This should make client-side object creation much easier via a standard ObjectMapper.

[talios]

Not wanting to hijack your issue here - but any suggestions on simplifying HalBuilder's API would be appreciated.

[gary-rowe]

No worries - glad to have your input here. Working on another project I noticed that the ReadableRepresentation doesn't work well with complex properties.

For example, when using .withBean() to create the representation I get a good JSON representation of the bean with its complex properties (think List<Map<String,ExampleDto>>). The JavaScript client code can get all the information. However when I come to use the ReadableRepresentation to read the JSON (via an entity InputStream) the complex property is flattened due to the use of .asText() for all property types.

I spent some time attempting to find a workaround before running out of time and resorting to a manual implementation of a simple EntityDto with Map<String, List<LinkDto>> for the _links section, and similar for _embedded. This worked a treat since suddenly all my Resources were working directly with DTOs. The downside was that I had to ensure that any _links or _embedded provided by the client were removed.

There is no way I can restructure the complex property into, say, an _embedded I am definitely stuck with it.

If HalBuilder could be made to provide a .getBean() method instead of relying on .getProperties() then this would probably solve the problem.

Also, I could just be using the library incorrectly so any advice you could offer would be appreciated.