Which schema is better in web service API design

Question

Recently, our team is going to develop mobile(iphone, android platforms) applications for our existing website, let user can use the application to more easy to read our content via the application.

But our team have different views in JSON schema of the API return, below are the sample response.

Schema type 1:

{
"success": 1,
"response": {
    "threads": [
        {
            "thread_id": 9999,
            "title": "Topic haha",
            "content": "blah blah blah",
            "category": {
                "category_id": 100,
                "category_name": "Chat Room",
                "category_permalink": "http://sample.com/category/100"
            },
            "user": {
                "user_id": 1,
                "name": "Hello World",
                "email": "helloworld@hello.com",
                "user_permalink": "http://sample.com/user/Hello_World"
            },
            "post_ts": "2012-12-01 18:16:00T0800"
        },
        {
            "thread_id": 9998,
            "title": "asdasdsad ",
            "content": "dsfdsfdsfds dsfdsf ds",
            "category": {
                "category_id": 101,
                "category_name": "Chat Room 2",
                "category_permalink": "http://sample.com/category/101"
            },
            "user": {
                "user_id": 2,
                "name": "Hello baby",
                "email": "hellobaby@hello.com",
                "user_permalink": "http://sample.com/user/2"
            },
            "post_ts": "2012-12-01 18:15:00T0800"
        }
    ]
}
}

Schema type 2:

{
"success": 1,
"response": {
    "threads": [
        {
            "thread_id": 9999,
            "title": "Topic haha",
            "content": "blah blah blah",
            "category": 100,
            "user": 1,
            "post_ts": "2012-12-01 18:16:00T0800"
        },
        {
            "thread_id": 9998,
            "title": "asdasdsad ",
            "content": "dsfdsfdsfds dsfdsf ds",
            "category": 101,
            "user": 2,
            "post_ts": "2012-12-01 18:15:00T0800"
        }
    ],
    "category": [
        {
            "category_id": 100,
            "category_name": "Chat Room",
            "category_permalink": "http://sample.com/category/100"
        },
        {
            "category_id": 101,
            "category_name": "Chat Room 2",
            "category_permalink": "http://sample.com/category/101"
        }
    ],
    "user": [
        {
            "user_id": 1,
            "name": "Hello World",
            "email": "helloworld@hello.com",
            "user_permalink": "http://sample.com/user/Hello_World"
        },
        {
            "user_id": 2,
            "name": "Hello baby",
            "email": "hellobaby@hello.com",
            "user_permalink": "http://sample.com/user/Hello_baby"
        }
    ]
}
}

Some Developers claim that if using schema type 2,

• can reduce data size if the category & user entities comes too much duplicated. it does really reduce at least 20~40% size of response plain text.
• once if the data size come less, in parsing it to JSON object, the memory get less
• categoey & user can be store in hash-map, easy to reuse
• reduce the overhead on retrieving data

I have no idea on it if schema type 2 does really enhanced. Because I read so many API documentation, never seen this type of schema design. For me, it looks like a relational database. So I have few questions, because I have no experience on designing a web services API.

• Does it against API design principle (Easy to read, Easy to use) ?
• Does it really get faster and get less memory resource on parsing on IOS / Android platform?
• Does it can reduce the overhead between client & server?

Thanks you.

Answer 1

When I do such an application for android, I parse JSON just one and put it in database. Later I'm using ContentProvider to access it. In Your case You could use 2nd schema but without user, category part. Use lazy loading instead but it will be good solution just in case categories and users repeat often.