Стоит ли исключать пустые поля из ответа сервера JSON в веб-приложении для уменьшения трафика?

Давайте скажем, что API хорошо документирован и описано все возможные поля ответа.

Если API сервера веб-приложений исключает пустые поля в ответе JSON для уменьшения количества трафика? Это хорошая идея?

Я пытался рассчитать объем трафика, уменьшенный для большого приложения, такого как Twitter, и цифры на самом деле довольно убедительны.

Например: если вы исключаете одно поле ответа, "someGenericProperty":null, что составляет 26 байт, из каждого ответа API, а в Twitter, как сообщается, имеется 13 миллиардов запросов API в день, объем сокращения трафика будет > 300 Gb.

Более 300 Гбайт трафика меньше, чем день, это довольно экономичная заставка, не так ли? Это, вероятно, самый наивный и упрощенный расчет когда-либо, но все же.

ОТВЕТЫ

Ответ 1

В общем, нет. Чем более популярным API и, тем больше потенциальными потребителями API, тем более инвариантным должен быть API.

  • Разработчики, начинающие работу с API, путаются, когда поле появляется несколько раз, но не в другое время. Это приводит к разочарованию и, в конечном счете, отнимает время API-интерфейса в виде запросов на поддержку.
  • Невозможно точно узнать, как пользователи по нисходящей линии используют API. Часто они не используют его так, как воображает разработчик API. Элементы, которые появляются или исчезают в зависимости от контекста, могут нарушать приложения, которые потребляют API. Разработчик API обычно не знает, когда было нарушено нисходящее приложение, за исключением жалоб от разработчиков, работающих ниже по течению.
  • Когда элементы данных появляются или исчезают, вводится неопределенность. Был ли элемент данных отправлен не потому, что API считал его неактуальным? Или изменился API? Или есть некоторая ошибка в коде потребителя, не правильно разбирающая ответ? Если потребитель ожидает поля, а его нет, как он отлаживается?
  • На стороне сервера необходим дополнительный код, чтобы вычеркнуть эти поля из ответа. Что делать, если логика, чтобы исключить данные? Это шанс ввести дефекты, и это означает, что существует больше кода, который должен поддерживаться.

Во многих приложениях латентность сети является доминирующим фактором, а не полосой пропускания. По соображениям производительности многие разработчики API будут одобрять несколько больших запросов/ответов по многим небольшим запросам/ответам. В моей последней компании системы продаж и биллинга будут регулярно обмениваться сообщениями в 100 КБ, 200 КБ или более. Иногда требовалось лишь несколько килобайт данных. Но общая производительность системы была лучше, чем выборка некоторых данных, поэтому было обнаружено, что больше было необходимо отправить дополнительный запрос для этих данных.

Для большинства приложений некоторая несогласованность более опасна, чем избыточные данные являются расточительными.

Как всегда, существует миллион исключений. Я когда-то брал интервью у работы на станции торпеды. У них были подводные датчики на их огневой дистанции для отслеживания торпед. Все данные датчиков передавались через акустические модемы в центральный подводный сборщик данных. Акустические подводные модемы? Да. При 300 бодах каждый байт подсчитывает.

Существуют встроенные приложения с батарейным питанием, в которых учитываются каждый байт, а также низкочастотные системы радиосвязи.

Другим исключением являются редкие данные. Например, представьте себе матрицу с 4 000 000 строк и 10 000 столбцов, где 99,99% значений матрицы равны нулю. Матрица должна быть представлена ​​с разреженной структурой данных, которая не включает нули.

Ответ 2

Он определенно зависит от службы и объема данных, которые она предоставляет; он должен оценивать отношение около нулевых/не нулевых данных и устанавливать пороговое значение, чем это стоит, чтобы исключить эти элементы. Спасибо, что поделились, это интересный момент для меня.

Ответ 3

Вопрос находится на неправильной стороне - JSON не лучший формат для сжатия или уменьшения трафика, но что-то вроде goob protobuffers или bson.

Я тщательно пересматриваю значения nullables в схеме API прямо сейчас. Мы используем swagger (Open API) и json scheme на самом деле не имеет ничего подобного типа NULL, и я думаю, что для этого есть веская причина.

Если у вас есть ответ JSON, который отображает целочисленное поле DB, которое внезапно становится NULL (или может быть в соответствии с схемой БД), хорошо, что это действительно нормально для реляционной БД, но не совсем здорово для вашего API.

Я предлагаю принять и следовать более элегантному подходу, и это будет to make better use of "required" также для ответа.

Если это поле является необязательным в схеме API ответа и оно имеет нулевое значение в БД, не возвращайте это поле.

Мы также включили строгие проверки схемы для ответов API, и это дает нам намного лучший контроль над нашими данными и заставляет нас не полагаться на состояния в API.

Для клиента API, который, конечно же, выполняет следующие проверки:

if ("key" in response) {
    console.log("Optional key value:" + response[key]);
} else {
    console.log("Optional key not found");
}