API doesn't support non-numeric IDs

[carlson]

The API represents ids as JSON numbers:

"id":999,
"service_id": 2

Is it the spec's intention that ids must be numbers? Some systems use GUIDs instead. The spec could handle this by treating ids as strings:

"id": "999"

or

"id": "4e8d861757bb9cf10b21c115"

[straup]

The spec as it currently written is agnostic on whether IDs should be numbers or strings. Requiring one over the other is probably just a recipe for annoying people :D

So yes: That should be cleared up, probably in api.md

Thanks!

[carlson]

OK, if left agnostic consumers of the API will need to handle ids with JSON data types that may vary across implementations. For example (in Java): String id = json.getString("id"); or int id json.getInt("id"); depending on the server's implementation. This is less of an issue in dynamically typed languages. Cheers.

[straup]

Yeah, it's not awesome. I've updated the spec to say that it probably means that clients will need to assume everything is a string.

I'm willing to be convinced otherwise but it seems easier to put that burden on clients rather than the technical infrastructure of any given city.

UIDs as strings will eventually incur a not insignificant cost in database indexes for a city with lots of records.

[carlson]

Right, was never suggesting the API should (or could) dictate what type of ids the server implementation uses, only which JSON data type (string or number or either) will be used when transferring ids between client & server.