Open gary-rowe opened 11 years ago
Not wanting to hijack your issue here - but any suggestions on simplifying HalBuilder's API would be appreciated.
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.
HalBuilder appears to introduce more complexity than is required for HAL support. Refactoring would include:
This should make client-side object creation much easier via a standard ObjectMapper.