DefaultCurieProvider has surprising behavior [DATAREST-513]

Willie Wheeler opened DATAREST-513 and commented

This applies at least to Spring HATEOAS 0.16.0 and 0.17.0.

The DefaultCurieProvider curies non-standard link relations. And that's not unreasonable. But the list of standard link relations is quite long, and it's easy to accidentally pick a rel with a standard name but nonstandard semantics. For example in my case I chose "service" to reference a particular kind of domain resource in my app (nothing to do with Atom), and I had to dive into the Spring HATEOAS code to figure out why all the other associations were being curied but not that one.

As a workaround I can just manually add the curie prefix using @RestResource(rel = "s:service"). Still I would offer that this isn't great. If I change the prefix then I have to hunt down all the rels where I applied this workaround, which is error prone.

My suggestion would be to add a @RestResource(applyCurie=true|false) (default true) element. This is based on the observation that the standard IANA rels wouldn't typically appear as entity associations anyway. For example, self, first, prev, next, last--these aren't going to be entity associations. The underlying philosophy here would be that the framework itself generates a small number of standard rels (self, etc.), and it assumes by default that entity association rels refer to domain resources with domain-specific semantics.

If you don't want to pollute @RestResource with HAL-specific concepts (arguably curies aren't HAL-specific, but for the sake of argument) then maybe there could be a separate @SuppressCurie annotation. But it would be better to decouple curies from HAL (currently they are in a o.s.hateoas.hal package) and support the systematic application of a curie strategy independently of HAL.

Affects: 2.3 GA (Fowler)