JSON Response from web service - best practices question

I'm writing a simple web service that return a JSON response. It'll be heavily used, so I want to try and make the JSON response as small as possible for performance reasons. I'm on the fence over a design decision; penny for your thoughts!

My JSON response from the server looks like this:

{
  "customers":
  [
    {
      "id": "337",
      "key": "APIfe45904开发者_运维技巧c"
    },
    {
      "id": "338",
      "key": "somethingDifferent"
    },
    {
      "id": "339",
      "key": "APIfe45904c"
    },
    {
      "id": "340",
      "key": "APIfe45904c"
    }
  ]
}

The APIfe45904c here is used in about 60-70% of the records, so I could also modify the the JSON response to remove the repeated information and add a default_key i.e. if there's no key specified, the client should assume the default_key like this:

{
  "default_key": "APIfe45904c",
  "customers":
  [
    {
      "id": "337"
    },
    {
      "id": "338",
      "key": "somethingDifferent"
    },
    {
      "id": "339"
    },
    {
      "id": "340"
    }
  ]
}

No client is using the web service yet, so this wouldn't break anything. Is this good practice? It works, and makes for a small JSON response, but I'm conflicted. I like the KISS principle for developers using the service, but I also want as small a JSON response as possible.

I was tempted to replace customers with c, id with i and key with k to aid reducing the file size, but I figured this will be a problem if I want to get other clients to start using it. Should I drop the idea of default_key for the same reason?

Each JSON response will likely be no more 200 lines of id/key pairs, so I don't need to incorporate pagination, etc.

---

I would keep it simple as you say, and then use gzip to compress it. It should compress very well as it is repetitive, and remains convenient for programmers.

See here for pointers in outputting gzip headers for AJAX: Is gzip encoding compatible with JSON?

---

Unless you have very special performance needs, I would always choose clarity over brevity. Especially for an API that is going to be used by many developers.

---

You should use the consistent format where each record has an id and a key field. What you lose in bandwidth you gain from not having to pre-process the JSON on the client-side.

I tend to analyze my JSON data structure like you but in the end it isn't worth the tiny bit of space you save. Your JSON data structure looks good... have you seen Twitter's JSON data structure? Now that is ugly.

---

I would go with the default key idea, but I wouldn't go as far as shortening the attribute names since that can be confusing. Perhaps you can take an argument from the web service call (from query string) that specifies whether or not the client desires to have shortened attribute names.