> What you need is to provide a set of functions able to map between these formats and whatever optimal way you want to store them in
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.
Personally I've always favored a JSON HATEOS approach with my API's, where the JSON response contains the actual URL's of the resources referenced, not just URN. Example from one API that I maintain:
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.
> As we iterated on our approach, we have decided to follow more recent recommendations and not limit our identifiers to the deprecated concept of URN.
I was not aware URN was deprecated... Is there a reference somewhere to these recommendations?
The use of the name URN in the broad sense of "a URI that specifies a name" is deprecated in favor of the general term URI (similar to the way that the term URL is deprecated in the same source) per RFC 3986.
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.
Is there a benefit of using tag URI instead of a regular old URL? E.g. tag:blogger.com,1999:blog-555 vs https://blogger.com/1999/blog-555 The only difference I see is that URL should point to something (can be referenced in a browser) which may or may not be an additional benefit.
[+] [-] jamiethompson|9 years ago|reply
[+] [-] kuschku|9 years ago|reply
[+] [-] bpicolo|9 years ago|reply
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.
[+] [-] pcalcado|9 years ago|reply
[+] [-] NathanKP|9 years ago|reply
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.
[+] [-] DorothySim|9 years ago|reply
I was not aware URN was deprecated... Is there a reference somewhere to these recommendations?
[+] [-] dragonwriter|9 years ago|reply
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.
[+] [-] awelynant|9 years ago|reply
[+] [-] DorothySim|9 years ago|reply
[+] [-] zeveb|9 years ago|reply