When using toResources(), "links" is not correctly marshalled

[fdw]

I'm using a method in a controller that returns a list of resources, built using toResources(). However, in the resulting json, the links are in a field called "links", and not "_links" as expected.

Example:

Code

public class ExampleResource extends ResourceSupport {
}

public class ExampleResourceAssembler extends ResourceAssemblerSupport<ExampleDao, ExampeResource> {
    public ExampleResource toResource(ExampleDao exampleDao) {
        // build resource and add link
    }
}

public List<ExampleResource> getProductInformation() {
    return exampleResourceAssembler.toResources(exampleDao);
}

Result:

[
  {
  "links": [
      {
        "rel": "self",
        "href": "http://localhost/example"
      }
    ]
  }
]

[odrotbohm]

A ResourceAssembler assembles resources, i.e. it's responsibility is to collect the model (links + payload). It does not determine which media type that resource will be eventually rendered as. That's the responsibility of the marshaling infrastructure (usually an HttpMessageConverter using Jackson and some integration per media type).

[fdw]

Sorry, I forgot: The controller is annotated with @RequestMapping(value = "/products", produces = "application/hal+json;charset=utf-8")

The same setup works with a single resource (i.e. not a list).

Do you need any other information?

[odrotbohm]

Are you sure the HAL support is actually activated using @EnableHypermediaSupport?

[fdw]

Yes, it is. As I said, the same setup works if I'm return just one resource instead of a list.

Oh, and we use spring-mvc-hateoas in version 0.21.0.RELEASE.

[DanailMinchev]

I have the same issue using default Spring Boot 1.4.1

As described here: http://docs.spring.io/spring-boot/docs/1.4.1.RELEASE/reference/htmlsingle/#boot-features-spring-hateoas:
I don't have @EnableHypermediaSupport, because I want Spring Boot's default configuration of HATEOAS.

So:

• when I request one ResourceSupport object with application/json (or .json extension) the response is entity with _links property and the same with HAL / application/hal+json
• when I request collection of List<UserResource> with application/json (or .json extension) the response is list of entities with links property and the same with HAL / application/hal+json

Looks like the media type is ignored and it is always _links for one resource and links for multiple resources.

[otrosien]

My feeling is, you're using the wrong (non-hal configured) jackson instance in your cases. It would be good to have a full example project on github to give you more detailed feedback.

[fdw]

Unfortunately, it would be quite complicated to post an example project, since we would need to strip out all proprietary code.

However, I can paste the relevant config snippets. The Controller, Resource and ResourceAssembler are as above.

@Configuration
@ComponentScan("com.example.rest")
@EnableHypermediaSupport(type = HAL)
@EnableWebMvc
public class MvcConfig extends WebMvcConfigurerAdapter {

  @Autowired private BeanFactory beanFactory;

  @Bean
  public ObjectMapper jacksonMapper() {
    ObjectMapper halObjectMapper = (ObjectMapper) beanFactory.getBean("_halObjectMapper");

    halObjectMapper.configure(WRITE_DATES_AS_TIMESTAMPS, false);
    halObjectMapper.registerModule(new AfterburnerModule());
    halObjectMapper.registerModule(new JodaModule());

    return halObjectMapper;
  }

  @Override
  public void configureDefaultServletHandling(DefaultServletHandlerConfigurer configurer) {
    configurer.enable();
  }

  @Override
  public void configureContentNegotiation(ContentNegotiationConfigurer c) {
    c.defaultContentType(MediaType.parseMediaType("application/hal+json"));
  }

[jochenchrist]

You could probably workaround wrapping your collection in Resources.

Instead of:

public List<ExampleResource> getProductInformation() {
    return exampleResourceAssembler.toResources(exampleDao);
}

return Resources

public Resources<ExampleResource> getProductInformation() {
    return exampleResourceAssembler.toResources(exampleDao);
}

However the rendering changes, as the list elements are embedded in an _embedded field.

[gregturn]

Is this related to #470, a PR that moved at add a UTF-8 based MediaType to compensate for Spring Boot moving to APPLICATION_JSON_UTF8 as the default "produces" for Spring MVC REST response types?

[fdw]

Hi @gregturn, I don't think so, no. Our problem highlights a different marshalling when using a List<? extends ResourceSupport instead of ResourceSupport. The first is wrong while the second works correctly, both using the same MediaType in the tests.

[abobwhite]

I am seeing this too. Been struggling with it for a couple weeks and can't find the reason.

[gregturn]

Pretty sure you need to use Resources to get the collection to render properly.

It's evident in the posted JSON where the top of the structure is an array not a map. Returning List<Resource> As your top level structure is not a valid HAL structure hence bypassing the HAL serializers.

[fdw]

But if using a List<? extends ResourceSupport> is wrong, why is there a toResources() method in ResourceAssemblerSupport? This is not very intuitive...

[gregturn]

ResourceAssemblerSupport has some problems. That's why I wrote #591.

In its current form, you should return a Resources with the contents of toResources inside it.

[gregturn]

Related to #416

[abobwhite]

@gregturn Makes sense, however, the ResourceAssembler toResources returns a List, not Resources....how would we go about managing that variance? Resources.wrap? Is there any preferred approach?

[gregturn]

If you look at #416, you'll notice the updated API stuffs that inside a Resources object. While you can't use the new code, you can certainly emulate it by inserting toResources into a new Resources object, and having your controller return that. That should certainly yield a different output.

[abobwhite]

@gregturn That indeed works and so does Resources.wrap....however, now everything is nested under a root _embedded object.....the fun continues.

[gregturn]

And when serving multiple resources in HAL, this is the proper format. non-_embedded is only for single items.

[odrotbohm]

But if using a List<? extends ResourceSupport> is wrong, why is there a toResources() method in ResourceAssemblerSupport? This is not very intuitive...

Hm, not sure I can follow. toResources() takes a list of elements and transforms each of them into Resource instances. I.e. you wrap each element to create hypermedia-enabled variants of those elements and a List of those. Whether you want to enable hypermedia aspects for the entire list, is a completely orthogonal decision. So the pattern we usually see is something like:

return new Resources<>(assembler.toResources(sourceList));

which makes both steps pretty obvious. I'd argue that's SRP principle in practice.

Maybe we can add a variant of that method (….map(…)?) that returns a builder which has to be concluded with either toList() or toResources()

[gregturn]

Hm, not sure I can follow. toResources() takes a list of elements and transforms each of them into Resource instances. I.e. you wrap each element to create hypermedia-enabled variants of those elements and a List of those.

This would be clearer if we didn't actually have a Resources type. Since we do, I think too many people assume that's what you get.

Additionally, people probably don't realize that Spring HATEOAS's hypermedia serialization doesn't kick in if a Spring MVC route don't return ResourceSupport or one of its subtypes. It's why I keep seeing issues opened showing.

To support things, I'm adjusting #632 to have both. Or if they are simply returning that output on a Spring MVC route, they can adjust suitably.

[gregturn]

The return type needs to be either ResourceSupport or one of its subtypes. The resource assemblers presently used now return these via #416 and #572. Update your Spring MVC endpoints return types and the JSON should render properly.