Ответ JSON от веб-службы - вопрос передового опыта

Question

Я пишу простой веб-сервис, который возвращает JSON-ответ. Он будет интенсивно использоваться, поэтому я хочу попытаться сделать ответ JSON как можно меньшим из соображений производительности. Я нахожусь на заборе из-за дизайнерского решения; копейки за мысли!

Мой ответ JSON от сервера выглядит следующим образом:

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

Здесь APIfe45904c используется примерно в 60-70% записей, поэтому я мог бы также изменить ответ JSON, чтобы удалить повторяющуюся информацию, и добавить default_key, т. Е. Если не указано key, клиент должен принять default_key следующим образом:

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

Ни один клиент еще не использует веб-сервис, так что это ничего не сломает. Это хорошая практика? Это работает, и делает небольшой ответ JSON, но я в конфликте. Мне нравится принцип KISS для разработчиков, использующих сервис, но я также хочу получить как можно меньший ответ JSON.

Мне хотелось заменить customers на c, id на i и key на k, чтобы помочь уменьшить размер файла, но я подумал, что это будет проблемой, если я захочу заставьте других клиентов начать использовать это. Должен ли я отказаться от идеи default_key по той же причине?

Каждый ответ JSON, скорее всего, будет содержать не более 200 строк пар идентификаторов / ключей, поэтому мне не нужно включать нумерацию страниц и т. Д.

Answer 1

Я бы сказал, что все будет просто, а затем используйте gzip для его сжатия.Он должен сжиматься очень хорошо, поскольку он повторяется, и остается удобным для программистов.

См. Здесь указатели для вывода заголовков gzip для AJAX: Совместимо ли кодирование gzip с JSON?

Answer 2

Если у вас нет особых требований к производительности, я бы всегда выбрал ясность, а не краткость.Специально для API, который будет использоваться многими разработчиками.

Answer 3

Я бы пошел с идеей ключа по умолчанию, но я бы не стал сокращать имена атрибутов, поскольку это может сбить с толку. Возможно, вы можете взять аргумент из вызова веб-службы (из строки запроса), который указывает, желает ли клиент сократить имена атрибутов.

Answer 4

Вы должны использовать согласованный формат, где каждая запись имеет поля id и key. То, что вы теряете в пропускной способности, вы получаете от отсутствия предварительной обработки JSON на стороне клиента.

Я склонен анализировать мою структуру данных JSON, как и вы, но в итоге она не стоит крошечного места, которое вы экономите Ваша структура данных JSON выглядит хорошо ... Вы видели структуру данных JSON в Twitter? Теперь это безобразно.