As you can see, Spring gives us multiple ways of achieving the same thing and it all depends on our preference or particular details of the implementation.

We covered three different ways of adding HttpMessageConverter to our application. So what is the difference, one might ask?

Declaring HttpMessageConverter as @Bean is the quickest and simplest way of adding a custom converter to the application. It is similar to how we added servlet filters in an earlier example. If Spring detects a bean of the HttpMessageConverter type, it will add it to the list automatically. If we did not have a WebConfiguration class that implements WebMvcConfigurer, it would have been the preferred approach.

When the application needs to define a more precise control over the settings, like interceptors, mappings, etc, it is best to use WebMvcConfigurer implementation to configure those, as it would be more consistent to override the configureMessageConverters method and add our converter to the list. As there can be multiple instances of WebMvcConfigurers, which could be either added by us or via the auto-configuration settings from various Spring Boot starters, there is no guarantee that our method can get called in any particular order.

If we need to do something even more drastic such as removing all the other converters from the list or clearing it of duplicate converters, this is where overriding extendMessageConverters comes into play. This method gets invoked after all the WebMvcConfigurers get called for configureMessageConverters and the list of converters is fully populated. Of course, it is entirely possible that some other instance of WebMvcConfigurer could override extendMessageConverters as well; but the chances of this are very low so you have a high degree of having the desired impact.