spring-hateoas: Keys for HAL's _embedded document and link relations do not follow the Jackson PropertyNamingStrategy configured

I have two beans in my configuration:

    @Bean
    public ObjectMapper getObjectMapper() {
        val objectMapper = new ObjectMapper();
        objectMapper.setPropertyNamingStrategy(SNAKE_CASE);
        objectMapper.registerModule(new AfterburnerModule());
        objectMapper.registerModule(new ProblemModule());
        objectMapper.setSerializationInclusion(JsonInclude.Include.NON_NULL);
        return objectMapper;
    }

    @Bean
    public Jackson2ObjectMapperBuilder getJackson2ObjectMapperBuilder() {
        val jackson2ObjectMapperBuilder = new Jackson2ObjectMapperBuilder();
        jackson2ObjectMapperBuilder.propertyNamingStrategy(SNAKE_CASE);
        return jackson2ObjectMapperBuilder;
    }

The problem is my response objects are still CAMEL_CASE so I don’t think Hateaos is using the correct bean. Am I writing the correct bean to change the naming strategy so that my response is entity_models and not entityModels?

Thanks!

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 19 (8 by maintainers)

Commits related to this issue

#1132 - HAL link relation rendering now applies Jackson's PropertyNamingStrategy. The rendering of HAL's link relations now applies Jackson's PropertyNamingStrategy if one is configured except it's a... — committed to spring-projects/spring-hateoas by odrotbohm 5 years ago

Most upvoted comments

Thanks, Marvin. That’s a lot of Interesting details.

If I read the spec correctly, the links only need to be absolute URIs if they’re used within a Link header. Also, the general rule seems to define either the reg-rel-type format or a URI. reg-rel-type is the format which registered relation types have to follow but that doesn’t mean link relation types need to be registered or URIs. Happy to learn that I’m wrong here 😃. That said, HAL CURIE mechanism allows to basically interpret all link relations as URIs by producing short versions of it that are valid URIs themselves.

What’s puzzling, too is that reg-rel-type only defines lower case characters to be allowed but the IANA list containing a few that use camel case.

I definitely take this as a vote for consistency here, thanks!

odrotbohm on Dec 5, 2019

This would guarantee consistency between the relations used in _links and _embedded.

From a spec point of view, the link relation type defines the kind of relation between to resources. So there’s no reason why a link relation type for an embedded resource should differ from a link relation type describing a link - the relation is semantically the same.

From a practical point of view, I’d also definitely argue in favor of consistent link relation types for _links and _embedded. We relied on this convention in our REST client to selectively optimize requests by embedding resources that were previously only linked in a represenation without having to change anything in the client (see implementation here).

In general, I’d like to point out that the Web Linking spec (RFC 8288) requires extension link relation types (meaning, link relation types that are not registered through IANA) to be URIs and the JSON-HAL spec references that RFC also in regards to _embedded. So if you want to be nitpicky, neither entityModelList nor entity_model_list are valid link relation types in the first place. But I guess in practice nobody cares about that … 🤷‍♂️

luchsamapparat on Dec 5, 2019

That’s helpful, Chad! I’ll have a look ASAP.

odrotbohm on Dec 3, 2019