Consider discouraging relative path URLs in the 'type' field

[pimterry]

Pulling this conversation out of #11:

Relative path URLs like out-of-funds act counter-intuitively. At first glance, they are some kind of api-global identifier, but in fact they should be considered as a path relative to the current resource, so an out-of-funds response from example.com/buy/123 is a totally distinct error type to an out-of-funds response from example.com/buy/456.

That is likely not what anybody intended. In addition, it appears that almost all implementations of this spec do not take that into account, parsing and comparing type URIs directly, and never using the resource URI that returned it at all.

This is a likely footgun for users implementing this spec, and there are easy better alternatives (see #13), so we should highlight that.

[sazzer]

so an out-of-funds response from example.com/buy/123 is a totally distinct error type to an out-of-funds response from example.com/buy/456

Minor but important nitpick - sorry! Those two examples are actually the same - the resolved value is example.com/buy/out-of-funds. The relative path in this case would replace the final path segment, not append to it.

A better example could be example.com/buy/123 vs example.com/lease/456.

This does fantastically highlight why relative URLs are difficult to use though :)

[pimterry]

Haha, good catch! The same would apply if I'd included a trailing slash too I think: example.com/buy/123/. Glad I've successfully illustrated my point though :facepalm:

[mnot]

I think this was addressed by #20 - can we close?

[pimterry]

Yes, I think so! :+1: