Objective C, JSON APIs and a few details worth noting...

Types that can be returned by JSON API:

• string
• number
• boolean
• null

When parsing JSON with Objective C's NSJSONSerialization class we get the following conversions:

• string (NSString)
• number (NSNumber)
• boolean (NSNumber*)
• null (NSNull*)

*Note that boolean to NSNumber will NSLog itself as __NSCFBoolean. What?! We just noted above that booleans get parsed as NSNumbers!! Okay, settle, it all does make sense with a little further explanation; __NSCFBoolean is a private class that is used in the NSNumber class cluster. Don't concern yourself with it. Understand that JSON response fields containing a boolean will get parsed as an NSNumber and that to check the parsed value for its meaning (i.e. true/false) you can NOT do if (myBoolean) or if (!myBoolean). Instead, you need to check if ([myBoolean boolValue]) or if (![myBoolean boolValue]) respectively.

*Note that null to NSNull is different than what you might hope for (null to nil). If you send a message to NSNull that it doesn't understand (this is easy to do if you're working with an optional string field), NSNull will crash your app (as opposed to just returning nil). Yikes!

So, how does it all add up? Well, from my experience as a PHP programmer, API developer, and iOS client creator... I'd break it down like this:

Strings, numbers, booleans, and nulls all serve a purpose on the server (both the backend database and API application layer (PHP)). For example, null means a value that hasn't yet been defined. We write queries using null, do special application logic based on it (i.e. send an email where we otherwise wouldn't, etc). It's true that in some cases the null value might even be important to the client, and if so, could be passed on through. However, from my experience, it rarely is. With Objective C being a strongly typed language and the risk of crashing being very real, I've found that I like writing APIs that simplify their output to just strings. 99% of the time, even when receiving a number from the API, I am getting it so I can display it in the UI (i.e. I need it as a string). Therefore the simplicity of working with an all strings API is wonderful and also helps avoid app crashes. I even like to switch my boolean values to strings and just use yes or no. I like the way it reads and keeps the entire API as strings only.

It's all about style. For me, I've found simplifying my API output makes for an easier to use JSON API for my iOS apps.