use AMF instead of JSON on iPhone? (for web services)

Question

Although iPhone support JSON natively, AMF is a binary protocol and it supposes to use much less bandwidth. Do you think using AMF is a good idea?

Just found this AMF library in cocoa (Objective-C): http://github.com/nesium/cocoa-amf/

Here's the famous benchmark that shows AMF is smaller and faster than JSON + gzip in Flex: http://www.jamesward.com/census/

Answer 1

I don't think AMF would be significantly smaller than JSON. In fact, it can be slightly larger in many cases. Let me show this in an example:

AMF stores the string "asdf" in the following binary format:

0x12            /* type = string */
0x00 0x04       /* length */
'a' 's' 'd' 'f'
/* total: strlen(s)+3 bytes */

while JSON stores the string "asdf" in strlen(s) + 2 bytes if there are no quotes in the string.

AMF stores the JSON object {"key1":"asdf","key2":"foo"} in the following binary format:

0x03             /* type = object */
0x00 0x04        /* length of key1 */
'k' 'e' 'y' '1'
0x02             /* value type = string */
0x00 0x04        /* length of value1 */
'a' 's' 'd' 'f'
0x00 0x04        /* length of key2 */
'k' 'e' 'y' '2'
0x02             /* type of value2 */
0x00 0x03        /* length of value2 */
'f' 'o' 'o'
0x00 0x00 0x09   /* end of object */
/* total: 30 bytes, while the JSON string is 28 bytes */

The above examples were in AMF0, but I don't think AMF3 would be much different.

The only feature in AMF0 that can significantly reduce the bandwidth is that it contains a reference type: if you send the same large object twice, the second object will be only a back-reference to the first instance. But it is a rare case IMHO (and it works only for objects, not for strings).

So I would recommend JSON (if you really want to spare on bytes, you can compress it with zlib or anything): it's much simpler to read, there are much more implementations, and the specification is clear (while the Flash implementation is sometimes different from the specification - we all like Adobe ;))