Closed dnikolovv closed 5 years ago
I'm a bit torn on this issue. In general I have no issue with a major version bum if it makes a better library, but adopting an expired "standard" for the sake of it, without clear benefit I do have a bit of an issue with.
In the JSON implementation I wanted the key to be the link name so developers could easily interact with it when parsed back to a javascript object.
I never really considered an XML implementation (mainly as I never needed it) but I fail to see what the problem is with:
<resource rel="self" href="/orders">
<link rel="next" href="/orders?page=2"/>
<link rel="find" href="/orders{/id}" templated="true"/>
</resource>
(ie do you need the controller detail at all? maybe that was a mistake in the JSON implementation).
Basically, can you re-iterate what the problem you're trying to solve actually is?
The problem was that you couldn't serialize to XML without losing the current rel tags.
If you're fine with the suggested XML template, I may tinker with the current implementation a bit to implement it? (as per this issue)
Let me know if that works for you.
By all means have a ticker, and submit a PR if appropriate. Happy to take submissions
If you look at the examples in the readme, you will see that the link names (e.g.
self
) are different from the link relations (therel
tag).This works okay but doesn't adhere to the Hypertext Application Language (HAL) standard.
Quoting the Wikipedia article -
Links have a target URI, as well as the name of the link (referred to as 'rel')
. However, the concept of a link name and itsrel
are separate in the current implementation.If we wanted to use XML instead of JSON (as mentioned in this issue) we don't know what approach to take.
In most examples (e.g. https://tools.ietf.org/html/draft-michaud-xml-hal-02#section-6) the value of the
rel
tag is what we would have as a link name in the JSON format.This is probably going to be a major change, bumping the current version to 4.0, but it needs to be decided.