issue #288: (Approach #2) Allow links on a particular rel to be displayed as an array even if there is only one link

[vivin]

Allows links under a single rel to be represented as a multiple (i.e., serialized to an array) even if there is only one.

This approach is a little better than the other one. Here, I created a new annotation that you can attach to a resource class. This annotation will contain a list of rels that will always be serialized as multiple links (i.e., in a JSON array) regardless of cardinality.

I did have to add a propertly to the Link class, which is just the class of the owning resource. The setter is package-private and so no one else can mess with it. The value of the field is set automatically when links are added.

I have also added a test for this case.

[odrotbohm]

What is "the other one" you're referring to. Link must neither know about ResourceSupport nor should it be made mutable. The annotation lookup looks rather hacky, too. Can we just extend the configuration options to HalHandlerInstantiator and tweak the rendering accordingly?

[vivin]

The other one had the setting on the Link itself which only applied to HAL. Yes, I agree this is not as clean as I would like.

I did try to do it via HalHandlerInstantiator. However, I ran into a few issues. The list of links is serialized by OptionalListJackson2Serializer. The idea is that we need to know if that particular rel on that particular resource needs to be forced into a multiple-link representation. In most cases it is not desirable that the rel be forced into an array representation across all resources. For example, I have a collection resource where I do want the rel to be forced into an array representation regardless of cardinality. But in another representation, I know that the resource described by the same rel will only ever have one instance and so the object representation is fine. So what I'm looking for is a way to force an array representation on specific resource-rel combinations.

I like the approach you suggested with the configuration options. I'm assuming that we would pass in the class of the resource and the rels that need to be forced into an array representation? Perhaps in some sort of map? I'll look into that option a little bit more. I think there would still be the problem of lacking context inside the OptionalListJackson2Serializer. How would we know that we need to force the list of links to be serialized into an array? We don't know which resource the link belongs to.

[vivin]

@olivergierke Do you know of a way how we can keep track of the resource that is also being serialized while its links are being serialized?

[vivin]

@olivergierke I've been looking into this to try and figure out how I can convey information to the list serializer regarding the owning resource. Do you have a suggestion as to how this can be accomplished? This is why I added the owningResource property. But if you know of a better way, please let me know! I'd like to get a fix for this as soon as possible because this is a real problem with the way the links are being serialized in HAL+JSON.

[vivin]

@olivergierke Another question (sorry for so many!). After thinking about this a bit more, I think I will take an approach where we always force certain rels to be serialized into an array. That is, instead of doing it based on the resource it belongs to, we do it regardless. So wherever the rel appears, it will always be serialized into a list of links. From an API-design perspective, I think this is what I was going for anyway (with regard to consistency).

My question is regarding configuration. Would you prefer that this be configured using an annotation (kind of like how we are doing it right now with @EnableHyperMediaSupport), or would you rather this information be inside a bean definition of some sort?

[vivin]

Closing this pull request. Please see #295.