Hacker News Reader

Comment by CodesInChaos | Hacker News Reader

I'd expect negative integer ids in an API to break even more integrations than unexpectedly large integers.

Though I guess that likelyhood is influenced by the choice of protocol. For example when using protobuf the client code generated from the specification file will use a 32-bit integer, if that's how it was defined. While in JSON I'd generally assume it's a positive integer smaller than 2^53.

View on HN

You don’t have to expose the negative to the customer - convert it to unsigned at the API layer, and bobs your uncle

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.

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