Ask HN: Why are URNs not more popular?

Re:Ask HN: Why are URNs not more popular? by Kwpolska on Saturday January 07, 2023 @10:03AM (#34288581)

A JSON object can solve all your problems. {"idSource": "dkCRV", "value": "12345"} or {"idSource": "plPESEL", "value": "2137"} would be quite obvious. If you’re working with a language that cares about types, you can also make idSource into an enum (so it’s harder to make a typo or implicitly forget about handling a value). And if your API offers a documentation (such as OpenAPI, or a GraphQL schema), the documentation will include a list of possible values, and tooling might even generate the nice enum for you.

Is it a standard? No. But does it need to be to be useful and obvious to everyone?

[ Parent | on HN ]

Re:Ask HN: Why are URNs not more popular? by dagss on Saturday January 07, 2023 @10:51AM (#34289136)

Agreed and in fact this is what is in our code even before I made the post. My main problem is that we have to invent this idSource string for all registries we support.

[ Parent | on HN ]

Re:Ask HN: Why are URNs not more popular? by Kwpolska on Saturday January 07, 2023 @12:08PM (#34290088)

What does “support” entail? Whether “we print its friendly name on the invoice before its value” or “we validate it, fetch the business data from the national registries and auto-fill the rest of the form”, you still need some special handling and registration. In that case, you don’t save much by using an existing scheme, and you there is a bigger risk of someone providing a schema you don’t support.

[ Parent | on HN ]