3 ms·
Right. You can have the best documentation: If they expose them as string and mention they're opaque? Then customers who parse them to uint will get bugs and b
by OptionOfT 1y ago
Right. You can have the best documentation:
If they expose them as string and mention they're opaque? Then customers who parse them to uint will get bugs and be unhappy.
Did they expose them as ints? Customers who used uints will be unhappy.
At `jobs[-2]` the front-end parsed the ids (exposed as strings, but ints under the cover).
The backend left them alone.
That caused some issues when building out shared libraries.
- Demiurge 1y agoWhat kind of API specifies that your number is int, uint, or bigint? According to a quick search, the formats for APIs are: JSON ~80%, XML ~15%, ~5% other.
- lazide 1y agoAnyone storing them in a DB, or using them in internal fields will likely have a surprise on their hands. Unless they store them as opaque strings anyway, which is the saner thing to do in these situations anyway.
- arjvik 1y agoSQL requires setting the max length of a string, and its quite reasonable to set it to len(2147483647)=10 if you were expecting 32-bit int IDs.
- lazide 1y agoIf your goal is storing opaque strings, that is a very silly thing to do. At that point you’re just blowing up storage for no reason. Just use an int if you’re that sure. Setting a string length to coincidentally the length of a int serialized to a string while doing no other validation on it is…. Just special.
- layer8 1y agoIf you expose them as strings, you might as well convert them to unsigned at the conversion point.
- deleted 1y ago[deleted]