4 ms·
A JSON object can solve all your problems. {"idSource": "dkCRV", "value": "12345"} or {"idSource": "plPESEL", "value": "2137"} would be quite obvious. If you’re
by Kwpolska 4y ago
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?
- dagss 4y agoAgreed 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.
- Kwpolska 4y agoWhat 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.