Hacker News Reader

Comment by OptionOfT | Hacker News Reader

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.

View on HN

What 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.

Anyone 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.

SQL 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.

If 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.

If you expose them as strings, you might as well convert them to unsigned at the conversion point.

Reply on news.ycombinator.com