Using Pseudo-URIs with Microservices
philcalcado.com
Using Pseudo-URIs with Microservices
1–10 of 22 posts
Re: Using Pseudo-URIs with Microservices
#2> 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?
Re: Using Pseudo-URIs with Microservices
#3> 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.
Re: Using Pseudo-URIs with Microservices
#4Curious if tag URI was considered https://en.m.wikipedia.org/wiki/Tag_URI_scheme
Re: Using Pseudo-URIs with Microservices
#5> 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 autho…
> 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.
That's what I also suspected. Thanks!
Re: Using Pseudo-URIs with Microservices
#6What's wrong with using UUIDs for microservice architectures?
Re: Using Pseudo-URIs with Microservices
#7Curious if tag URI was considered https://en.m.wikipedia.org/wiki/Tag_URI_scheme
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.
Re: Using Pseudo-URIs with Microservices
#8 > 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.
It can become a big, unfun problem pretty fast.
Re: Using Pseudo-URIs with Microservices
#9Curious if tag URI was considered https://en.m.wikipedia.org/wiki/Tag_URI_scheme
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.
I worked on a project that used "regular old URL" just like you suggest, for contract and service identifiers, which needed to be human read/write/generatable
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
Re: Using Pseudo-URIs with Microservices
#10Curious if tag URI was considered https://en.m.wikipedia.org/wiki/Tag_URI_scheme
That looks like exactly the right solution to the author's problem.