Tell me more ×
Stack Apps is a question and answer site for apps, scripts, and development with the Stack Exchange API. It's 100% free, no registration required.
up vote 2 down vote favorite
1

number is an very ambiguous term.

It would be helpful if there was an indication of values that can return as non-integral.

In a javascript context this is not an issue, but most devs, myself included, need to know when to use an int/long vs double/decimal in order to properly define schemas and objects.

a possible solution would be to follow MS format and indicate with an integer flag.

update:

yes, I understand that you are returning a 'number' so technically the spec is correct. but what good does that do your audience?

Should I make every object field and database column a float so it doesn't break unexpectedly because I guessed wrong what datatype I should use?

Sure, I can guess, and correctly in most cases, but you are not guessing and your data fields are not all floats - are you picking up what I am putting down?

number is of questionable value to all but the most trivial applications of the api and downgrading the spec because of the limitations of transport is a mistake in my opinion.

share|improve this question
On the flip side, what good does decimal do a developer working in javascript? float, real, double, etc. are all constructs of particular languages; number at least has a concrete meaning in context. – Kevin Montrose♦ Jun 1 '10 at 21:53
@kevin - I think we have a disconnect here. I am not suggesting that you CHANGE the type as listed, I am suggesting that an additional hint indicating whether the field is integral or not for those not working in JS - which is MOST of us. – Sky Sanders Jun 1 '10 at 22:43
decimal doesn't exist in Java as a primitive type; real is pretty vague; lets not even get started on strictfp. I'm just saying, its a lot more complicated than you're making it out to be. integral/non-integral even raises some length issues (dates > 32 bits, most everything else <= 32 bits; signed/unsigned is another question). – Kevin Montrose♦ Jun 1 '10 at 22:56
@kevin - it is not complicated at all from my perspective: the single concern is whether to declare all 'number' fields in the api as double/float to accomodate the possible values represented by 'number' or add a note to the field description indicating that there will be no freakin decimal points in the value. Should an API spec make people guess? My experience is no, an API spec should server to remove amibiguities. – Sky Sanders Jun 1 '10 at 23:47
Your perspective is colored by a single use case; simply specifying the presence of a decimal point is the wrong thing to do here. You're basically proposing making the spec incorrect in the pursuit of fewer ambiguities. I do agree that number needs to be made more specific, but doing so is non-trivial and accordingly will take some time. – Kevin Montrose♦ Jun 2 '10 at 0:32
@kevin - we seem to be arriving at the same place, regardless of the route. thanks for taking the time to talk about it. – Sky Sanders Jun 2 '10 at 1:31

1 Answer

up vote 2 down vote accepted

We're using number in the JSON sense of the word. number in that context does cover all the data types we're returning.

I suppose it could be tightened up a bit, though...

Descriptions of the types of number coming back are now part of the /help docs.

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged