I actually like the idea of versioning the API. Having an API version
that returns all values as strings can be as simple on the Twitter
side as an IF statement in the final stages of constructing the JSON
output that just converts all numerical values to strings before the
JSON encode.


On Sep 25, 10:57 pm, jmathai <jmat...@gmail.com> wrote:
> Dewald sums it up great.  I'm not affected by this issue but keeping
> the barrier of entry low is of high value.  It sucks that some PHP
> installations have this issue, but if there's a good way to accomodate
> such a popular language then what's the harm?
> This brings up an issue though.  I'm not in favor of changing the
> default int to a string.  It's the default that's important.  Adding
> in an override parameter isn't really anymore helpful than suggesting
> to parse the json once you get it.  Except, the thought of pre-parsing
> json (no matter how simple) makes my stomach churn.
> Think about it from the perspective of a developer that's just
> starting with the API.  What would trip them up?  If there's a way to
> resolve that, then that should be a high priority.
> For me it's not a big deal since I've used it enough and know people
> in the API community and this group where I can get an answer.  That's
> a luxury I didn't have when I started though.
> So far, two proposed solutions:
>  * Abraham suggested an additional key (this is great because you see
> it in the response without having to know of an additional paramter)
>  * I suggested an additional parameter which would return all values
> as a string (drawback is that this is a bit more "hidden" - not
> everyone RTM :( )
>  * Your suggestion here!
> Think about the children! :)

Reply via email to