So, for example, a URN which uses UUID's to satisfy uniqueness yet still allows for categorization could look like:
urn:some-company:resource-type:abcdef012-3456-...
In practice, my opinion is that the registration step is largely not required if the URN's are used strictly as an implementation detail within a system. However, those publicized and/or having a reasonable chance of being persisted by an external actor should have a sufficiently unique NID such that it can be registered and, more importantly, does not have a coincidental collision with other systems generating URN's.
One important thing to remember with taking this approach is that you can work yourself into a huge bind if you store the mapped-versions in logs/other persistent storage and end up needing to change formats later. Say the original mapping version is based on 32 bit integers, or is cryptographically signed and your keys get exposed. If rolling the functions means you can no longer identify objects from logs / in databases, that's a huge problem.
That means things like access logs will no longer map to their respective current versions unless you keep around two separate encoder/decoders and are able to guess which version you need all the time.
It can become a big, unfun problem pretty fast.
https://changelogs.md/api/recently-crawled/
One major advantage of this is that it allows clients to be built which have no hardcoded URL's at all (other than perhaps the top level URI that gives them the list of URL's that the API exposes). This allows the API maintainer to adjust resource paths retroactively, in addition to just exposing an API that is easy to explore.
I was not aware URN was deprecated... Is there a reference somewhere to these recommendations?
The use of URN for a specific URI scheme that provides names, for which there is a global registry of namespaces to ensure uniqueness, etc.—which is what the article discusses—is in now way deprecated. The author seems to be ill-informed on the point which apparently is the only stated reason for not using the internet standard that directly applies to the use case.
Whatever the URN reference is intended to mean, this seems to be custom-over-standard with less clear justification than I would want for that choice.
That's what I also suspected. Thanks!
Tag URIs would have been better because:
a) not everyone owns a domain, but tags allow email address as authority
b) it's confusing to many people to overload http URIs this way
c) as a contract identifier the URI doesn't need to point to anything, but this creates cognitive dissonance — this is probably part of b)
d) too damn long — tag URIs might suffer from this too. We were using these all over the place and there's no good way to truncate them
You don't need to control a domain name to issue tags.
Tags issued under an authority (domain name or not) are associated with a time, so remain valid and unique even if you abandon or lose the domain name, etc., providing the authority in the future.
Because tag URIs are explicitly not a scheme that provides location information, the resource does not have to be accessible by a particular protocol for the tag to be meaningful and accurate, and the URI doesn't communicate false expectations to readers familiar with the scheme when the resource is not accessible. (And, for similar reasons, tags don't risk conflicting with actual locators in the future.)