HalEmbeddedBuilder should consider curies for relation types

[edrik]

At the moment it would be hard to use Resources for implementing the Hypertext Cache Pattern if using a CurieProvider.

According to the HAL spec the type of rel for "_link" and "_embedded" should be considered equal. So embedding resources should also result in a rel with a curie when provided.

[fiddlerpianist]

Yes, I've run into this problem as well. I don't think curies are really ready for prime time, not just here at Spring HATEOAS. I think there are some fundamental misunderstandings about what they are for. I'd say it's just better to use the full relation URL always; that way you don't run into client (or server) assumptions about when and where to provide curies.

[edrik]

I don't see anything wrong with Curie's per say (that people don't understand what they are for don't make them bad). And CurieProvider actually works for my use case where i serve several api paths under different "namespaces" and still refer to the rels with simple names and get the curies/namespace added accordingly. Just need the CurieProvider to be used for all rel's.

And curies also fills another important purpose of not adding the requirement to hard-code clients to full relation URL's and to serve relation documentation on a single base URL. This is especially important when the a API is deployed on several totally independent deployments.

[fiddlerpianist]

A curie is just a shorthand for a URI. It works exactly the way an XML namespace prefix works, except that the local name is less restrictive.

The client should never code directly to a curie without knowing what the base URL is (as in XML prefixes), as it is subject to change and scoped completely within the resource representation. Therefore, your second paragraph doesn't really make sense.

[edrik]

True that a link rel must be evaluated after converting to URIs if serialised in a different format, such as a Curie, and not blindly rely on the namespace prefix.

That still makes it possible to build a client with the relaxed evaluation of link rel's relative to the API deployment in question. That actually makes the link rel more closely scoped for the actual resource representation, because in my case there is no one true version of the link rel in question. The specification and documentation of the rel continues to evolve so another deployment may have a newer version of the spec.

I cant see any other options if you want to bundle the link rel documentation per deployment and have the curie actually point at the documentation. Dynamic evaluation of curie URIs becomes part of the client contract in a way, and that is a compromise I am willing to take in order to have simpler and reusable client code.

Still this has no bearing on the this issue in question :)
You can use @Relation to map the class rel to the namespaced rel directly. But that defeats the purpose of CurieProvider that preferably should take care of that.

[odrotbohm]

Seems to be related to #229, #233.

[odrotbohm]

Implemented by the fix for #229, #233.