4 ms·

Is there a reason you're not using numbers in the json output? "vehicle_id": "1" is better represented as: "vehicle_id": 1

• wise_young_man 12y ago
  What if the integer exceeds the maximum allowed on 32 bit machines and you try to decode the JSON?
  • djtriptych 12y ago
    That has nothing to do with JSON, which allows numbers of arbitrary size.
  • paulhallett 12y ago
    This is mostly just a typo in the examples I put, but I will consider using only strings for this type of stuff, to avoid issues.
    • idlewan 12y ago
      Given the dataset you have to serve, I don't think you'll be having any issues if most of the JSON parsers give you 32bit integers.
• erydo 12y ago
  I usually do the same thing. Both the 32-bit issue (that issue being with JSON libraries, not the spec) but also: IDs are opaque tokens. If down the road it makes sense to use UUIDs or have a sharding hash or something else, you don't want clients tied to expecting an integer datatype.
  • Igglyboo 12y ago
    I feel like a lot of people will see that an just cast it to an int however.
    • erydo 12y ago
      That could happen but in a lot of strictly typed languages it would be non-obvious and special effort to do so. There's absolutely no justification to send ints when you have any reasonable chance of needing to change it to a string later. Besides, IDs in a public API fundamentally are not numbers. You don't add them, subtract them, multiply them, shift them, inspect any property of them besides equality, or anything. They're opaque tokens used to identify things with the server.